Open Stack

On Fri, May 8, 2015 at 4:23 AM, Sean Dague <sean at dague.net> wrote:

> On 05/08/2015 07:13 AM, Robert Collins wrote:
> > On 8 May 2015 at 22:54, Sean Dague <sean at dague.net> wrote:
> >> I'm slightly confused how we got there, because we do try to install
> >> everything all at once in the test jobs -
> >>
> http://logs.openstack.org/83/181083/1/check/check-requirements-integration-dsvm/4effcf7/console.html#_2015-05-07_17_49_26_699
> >>
> >> And it seemed to work, you can find similar lines in previous changes as
> >> well. That was specifically added as a check for these kinds of issues.
> >> Is this a race in the resolution?
> >
> > What resolution :).
> >
> > So what happens with pip install -r
> > /opt/stack/new/requirements/global-requirements.txt is that the
> > constraints in that file are all immediately put into pip's state,
> > including oslo.config >= 1.11.0, and then all other constraints that
> > reference to oslo.config are simply ignored. this is 1b (and 2a) on
> > https://github.com/pypa/pip/issues/988.
> >
> > IOW we haven't been testing what we've thought we've been testing.
> > What we've been testing is that 'python setup.py install X' for X in
> > global-requirements.txt works, which sadly doesn't tell us a lot at
> > all.
> >
> > So, as I have a working (but unpolished) resolver, when I try to do
> > the same thing, it chews away at the problem and concludes that no, it
> > can't do it - because its no longer ignoring the additional
> > constraints.
> >
> > To get out of the hole, we might consider using pip-compile now as a
> > warning job - if it can succeed we'll be able to be reasonably
> > confident that pip itself will succeed once the resolver is merged.
> >
> > The resolver I have doesn't preserve the '1b' feature at all at this
> > point, and we're going to need to find a way to separate out 'I want
> > X' from 'I want X and I know better than you', which will let folk get
> > into tasty tasty trouble (like we're in now).
>
> Gotcha, so, yes, so the subtleties of pip were lost here.
>
> Instead of using another tool, could we make a version of this job pull
> and use the prerelease version of your pip code. Then we can run the
> same tests and fix them in a non voting job against this code that has
> not yet released.
>
>
Once we are actually testing that all of global requirements is
co-installable  will we end up with even more cases like this? Or is this
just an artifact of capping fro kilo?
https://review.openstack.org/#/c/166377/


>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150508/084d062d/attachment.html>