On 11/04/2015 03:27 PM, Clark Boylan wrote: > On Wed, Nov 4, 2015, at 09:14 AM, Sean Dague wrote: >> On 11/04/2015 12:10 PM, Jeremy Stanley wrote: >>> On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: >>>> On 11/04/2015 06:47 AM, Sean Dague wrote: >>> [...] >>>>> Is there a nodepool cache strategy where we could pre build these? A 25% >>>>> performance win comes out the other side if there is a strategy here. >>>> >>>> python wheel repo could help maybe? >>> >>> That's along the lines of how I expect we'd need to solve it. >>> Basically add a new DIB element to openstack-infra/project-config in >>> nodepool/elements (or extend the cache-devstack element already >>> there) to figure out which version(s) it needs to prebuild and then >>> populate a wheelhouse which can be leveraged by the jobs running on >>> the resulting diskimage. The test scripts in the >>> openstack/requirements repo may already have much of this logic >>> implemented for the purpose of testing that we can build sane wheels >>> of all our requirements. >>> >>> This of course misses situations where the requirements change and >>> the diskimages haven't been rebuilt or in jobs testing proposed >>> changes which explicitly alter these requirements, but could be >>> augmented by similar mechanisms in devstack itself to avoid building >>> them more than once. >> >> Ok, so given that pip automatically builds a local wheel cache now when >> it installs this... is it as simple as >> https://review.openstack.org/#/c/241692/ ? > It is not that simple and this change will probably need to be reverted. > We don't install the build deps for these packages during the dib run. > We only add them to the appropriate apt/yum caches. This means that the > image builds will start to fail because lxml won't find libxml2-dev and > whatever other headers packages it needs in order to link against the > appropriate libs. > > The issue here is we do our best to force devstack to do the work at run > time to make sure that devstack-gate or our images aren't masking some > bug or become a required part of the devstack process. This means that > none of these packages are installed and won't be available to the pip > install.
This seems like incorrect logic. We should test devstack can do all the things on a devstack change, not on every neutron / trove / nova change. I'm fine if we want to have a slow version of this for devstack testing which starts from a massively stripped down state, but for the 99% of patches that aren't devstack changes, this seems like overkill. > We have already had to revert a similar change in the past and at the > time the basic agreement was we should go back to building wheel package > mirrors that jobs could take advantage of. That work floundered due to a > lack of reviews, but I still think that is the correct way to solve this > problem. Basic idea for that is to have some periodic jobs build a > distro/arch/release specific wheel cache then rsync that over to all our > pypi mirrors for use by the jobs. > > Clark > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
