Skip to main content
Home
  • Home
  • About

Using pypi-mirror with devtest

  1. Home ยป
  2. Using pypi-mirror with devtest
Thu, 03/27/2014 - 16:45 by bnemec

A full run of TripleO's devtest takes a long time - around an hour or more on my i7/16GB box even with a hot squid cache. Quite a bit of the time is spent building images, and there are a few ways to speed that up, some of which are easier than others.

In the past I've used the pip-cache and pypi-openstack image elements along with the aforementioned squid cache to decrease image build times, but there's been quite a bit of discussion lately around using pypi-mirror and the pypi element. These aren't especially new elements, but they do require some work up front so I had never tried them myself.

This week I decided to change that. I built a pypi-mirror manually on my existing proxy VM by following the steps in the pypi-mirror script, but I don't particularly recommend that method because I messed up some steps and in the end it probably took longer than just building and deploying a new image would have. Either way, my local pypi mirror is now up and running, and this morning I was able to complete a full devtest run to see how much faster it was. I had to set the following env vars:

# These two are documented in the pypi element
export PYPI_MIRROR_URL=http://roxy/pypi/Fedora-20
export PYPI_MIRROR_URL_1=http://roxy/pypi/
# I had to set this one because my pypi-mirror wheels were built for 64-bit, so if I wanted to use them I had to make sure the archs matched. Update: I just did a 32-bit run against the local mirror without using wheels and most of the speed benefit went away, so I don't recommend doing that.
export NODE_ARCH="amd64"
export DIB_COMMON_ELEMENTS="stackuser pip-cache pypi"

Then I ran devtest.sh --trash-my-machine and compared the results to a previous run. Here are the contents of devtest_perf.log (which you can find in your TRIPLEO_ROOT directory after a successful run) before and after setting up the mirror:

[2014-03-24 20:27:31] Run comment : No Comment
[2014-03-24 20:27:31] Total runtime: 3206 s
[2014-03-24 20:27:31] ramdisk : 165 s
[2014-03-24 20:27:31] seed : 700 s
[2014-03-24 20:27:31] undercloud : 790 s
[2014-03-24 20:27:31] overcloud : 1539 s
[2014-03-24 20:27:31] DIB_COMMON_ELEMENTS=stackuser pip-cache pypi-openstack use-ephemeral
[2014-03-27 15:37:02] Run comment : No Comment
[2014-03-27 15:37:02] Total runtime: 2675 s
[2014-03-27 15:37:02] ramdisk : 124 s
[2014-03-27 15:37:02] seed : 539 s
[2014-03-27 15:37:02] undercloud : 639 s
[2014-03-27 15:37:02] overcloud : 1320 s
[2014-03-27 15:37:02] DIB_COMMON_ELEMENTS=stackuser pip-cache pypi use-ephemeral

Around 9 minutes less for the full run, and that's comparing to a hot cache. If you were running with a cold/no cache I expect the difference would be much larger. I left the pip-cache element since the drawbacks to that element don't matter to me, and I figured it couldn't hurt.

Now that I've got my mirror set up and added the appropriate env vars to my tripleo rc file, I shouldn't have to do much to take advantage of this added speed, which should be a big win for my future development. If I can find a way to avoid hitting an external mirror for package installs (I don't think running a full distro mirror locally is an option, but we'll see), I might be able to keep my image installs entirely on my local gigabit network. Stay tuned. :-)

Tags:

  • OpenStack
  • TripleO
  • Performance
  • DevelopmentEnvironment
  • Log in to post comments

User login

  • Reset password
/dev/random DevelopmentEnvironment Networking OpenShift OpenStack Oslo OVB QuintupleO Servers Summit Testing TripleO

Syndicate

Subscribe to Subscribe to promoted content

Disclaimer

This site is not endorsed by Red Hat or anyone else. Egregious errors are all mine.

Powered by Backdrop CMS