Open Stack

On Wed, 18 Nov 2015 02:07:45 PM Ihar Hrachyshka wrote:
> Robert Collins <robertc at robertcollins.net> wrote:
> > On 14 November 2015 at 02:53, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> >> I was recently looking into how stable/liberty branches are set for
> >> neutron
> >> in terms of requirements caps, and I realized that we don’t have neither
> >> version caps nor upper constraints applied to unit test jobs in
> >> stable/liberty gate. We have -constraints targets defined in tox.ini, but
> >> they are not running in gate.
> >> 
> >> I believe this situation leaves us open to breakages by any random
> >> library
> >> releases out there. Am I right? If so, I would like to close the breakage
> >> vector for projects I care (all neutron stadium).
> >> 
> >> I suggest we do the following:
> >> 
> >> - unless there is some specific reason for that, stop running
> >> unconstrained
> >> jobs in neutron/master;
> > 
> > Sachi King is working up a bit of data mining to confirm that the
> > constraints jobs are only failing when unconstrained jobs fail - then
> > we're going to propose the change to project-config to switch around
> > which vote.
> 
> For what I saw in neutron, it never fails unless there is actual constraint
> not bumped.

Scraping before flipping the switch was just to be really sure we were not 
going to break anything before we went for it.  After scraping master and 
stable/liberty everything does indeed look good.  The script found some 
issues, but they were all caused by a bug in a tox release. 

If anyone is interested in pulling the stats out to verify I have uploaded my 
scraper to [0].  It's rough, but it got me the data.

> >> - enable voting for constraints jobs in neutron/liberty; once proved to
> >> work
> >> fine, stop running unconstrained jobs in neutron/liberty;
> > 
> > I expect the same query can answer this as well.
> > 
> >> - for neutron-*aas, introduce constraints targets in tox.ini, enable
> >> jobs in
> >> gate; make them vote there/remove old jobs;
> >> - after that, backport constraints targets to stable/liberty; make them
> >> vote
> >> there/remove old jobs.
> > 
> > We're going to advocate widespread adoption once the neutron master
> > ones are voting
> > 
> >> Does the plan make sense?
> > 
> > Totally :) As non-Neutron-contributors we've just been conservative in
> > our recommendations; if Neutron wants to move a little faster by
> > taking on a little risk, thats *totally cool* IMO.
> 
> I believe there is general understanding that it’s the way to go, and we
> were already happy to be guinea pigs for initial data mining, so I don’t
> expect problems getting the core team onboard.
> 
> My question was more about what we do with stable/liberty branches. Is it
> part of the plan that we backport the constraint jobs there?

Yes, the plan is to switch the -constraints jobs to voting in liberty as well.  
We've got -constraints operating in a non-voting fasion there just as in 
master and it looks good to flip over as well.

I've pushed [1] up for review to flip neutron's -constraints to voting on both 
master and liberty.  I could definatly use some eyes over it, as well as voice 
from the neutron team to give the signal that it has the go-ahead.

[0] https://github.com/nakato/checkconstraints
[1] https://review.openstack.org/#/c/247306/

Cheers,
Sachi