Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty

[Ihar Hrachyshka]

Robert Collins  wrote:


On 14 November 2015 at 02:53, Ihar Hrachyshka  wrote:

Hi Sachi and all,

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.


- 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?


Ihar

__
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

Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty

[Sachi King]

On Wed, 18 Nov 2015 02:07:45 PM Ihar Hrachyshka wrote:
> Robert Collins  wrote:
> > On 14 November 2015 at 02:53, Ihar Hrachyshka  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



__
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

Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty

[Robert Collins]

On 14 November 2015 at 02:53, Ihar Hrachyshka  wrote:
> Hi Sachi and all,
>
> 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.

> - 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.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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

[openstack-dev] [stable][neutron] upper constraints for stable/liberty

[Ihar Hrachyshka]

Hi Sachi and all,

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;
- enable voting for constraints jobs in neutron/liberty; once proved to  
work fine, stop running unconstrained jobs in neutron/liberty;
- 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.


Does the plan make sense?

Ihar

__
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