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.

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

Reply via email to