Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty
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 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
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
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