On Wed, 18 Nov 2015 02:07:45 PM Ihar Hrachyshka wrote: > Robert Collins <[email protected]> wrote: > > On 14 November 2015 at 02:53, Ihar Hrachyshka <[email protected]> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
