Open Stack

On Thu, 2012-11-01 at 12:56 +0100, Monty Taylor wrote:
> 
> On 11/01/2012 08:28 AM, Mark McLoughlin wrote:
> > On Wed, 2012-10-31 at 12:57 +0000, Pádraig Brady wrote:
> >> On 10/31/2012 12:08 PM, Gary Kotton wrote:
> >>> Hi,
> >>> Whilst back porting patches to the Quantum stable folsom branch I have encountered a very frustrating problem which I think that should be discussed. All of the stable quantum patches approved in the last few hours are failing unit tests. This seems to be due to one of the imported packages being problematic (the hunch at the moment is that this could be sqlalchemy). At the moment this is under investigation. I am wondering if when we create a stable branch, we should specifically set the pip-requires package numbers.
> >>> Any thoughts?
> >>> Thanks
> >>> Gary
> >>
> >> This was discussed at the design summit, with notes kept here:
> >> https://etherpad.openstack.org/process-dependency-management
> >>
> >> One of the action items from there is:
> >>
> >> * freeze 'sane' version (max major version?) range at release time
> >>
> >> So by recording the max version in the pip-requires,
> >> it would mean that newer versions wouldn't be pulled
> >> in, in the future, that might break stuff.
> >> Also distros etc. should not be impacted since packages
> >> manage dependencies independently.
> > 
> > Yep, I think we should go this route.
> > 
> > Basically, on master we should be testing the latest versions of
> > libraries as they are released because the next release needs to work on
> > distros with the very latest libraries.
> > 
> > On the stable branch, I think we mostly just want to keep the gate
> > working and not be randomly impacted by new libraries.
> > 
> > The question is how to do this. The Jenkins gate job runs 'pip freeze'
> > so we have a source of this info:
> > 
> >   http://logs.openstack.org/13829/1/gate/gate-quantum-python27/1696/console.html.gz
> > 
> > and since that's the commit which started the stable/folsom branch, it
> > should be the list we want.
> > 
> > So we can take that 'pip freeze' output and use it to update the
> > pip-requires. I've re-purposed a script Monty wrote for this:
> > 
> >   https://gist.github.com/3992317
> > 
> > and the result looks like this:
> > 
> >   https://review.openstack.org/15186
> > 
> > Thoughts?
> 
> I think the general approach is great - but I think that doing an
> absolute == has the potential to break current releases on older distro
> versions. Instead, if we add a ,<=current_version to the end of the
> version string, then we protect ourselves from new unexpected pypi
> releases without asserting a new lower-bound on acceptable older library
> releases which may or may not be a valid assertion.

tl;dr of below is that we had agreed on a solution for this at summit
and then forgot about it until now. We'll drop the version pinning idea
and have the Jenkings nightly-stable jobs send email notifications to
the stable-maint team

---

Monty and I just discussed this on IRC and the discussion turned pretty
heated when he reminded me that the versions in pip-requires are also
included in setup.py :)

Basically, Monty's concern about using == is that you'd be prevented
from doing 'python setup.py install' with older versions of the
requirements installed. I'm similarly concerned about not being able to
do that with *newer* versions of the requirements installed.

Where we got to in the end is that the issue of keeping the stable gate
running on a stable set of library versions is the issue everyone wants
to see resolved now and we've pretty good consensus on that. The issue
of what goes into install_requires in setup.py requires much more
discussion.

So, I was going to propose a patch that would add frozen-pip-requires
with the specific versions pinned there and make tox use that for
testing purposes.

After some more discussion we realized we do actually want to catch
cases where a new library version comes along and breaks things. Having
the gate running on a frozen set of versions would mean we don't catch
this.

And after all of this, we remembered that Jenkins actually runs the gate
tests nightly on stable/folsom and we had agreed that email
notifications about failures of those should go to the stable-maint
team. That way we should quickly catch such issues and update
pip-requires as appropriate.

Cheers,
Mark.