Neil, Apologies. you are right, test_bash_completion is a unit test. and neutron failure is in "gate-neutron-python27-constraints". so yes, that was broken by the change to upper-constraints.txt.
https://review.openstack.org/#/c/266042/ is a valid request as it has a g-r change and a u-c change even though it was not logged by the Bot. Thanks, dims On Thu, Jan 14, 2016 at 7:09 AM, Neil Jerram <neil.jer...@metaswitch.com> wrote: > On 14/01/16 12:01, Davanum Srinivas wrote: >> Neil, >> >> The global requirements upper-constraints.txt do not cover neutron >> unit test targets. So the unit tests pick up latest from pypi. > > I'm afraid I don't understand how that's related to my question below. > Could you explain further? > > It seems you might be saying that upper-constraints.txt should have no > effect on Neutron UTs. But my understanding from Carl's message is that > an upper-constraints.txt change caused a Neutron UT (running as part of > a gate job) to fail. So I'm not sure how to understand your statement. > > Thanks, > Neil > > >> >> -- Dims >> >> >> >> On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram <neil.jer...@metaswitch.com> >> wrote: >>> On 13/01/16 19:27, Carl Baldwin wrote: >>>> Hi, >>>> >>>> I was looking at the most recent gate breakage in Neutron [1], fixed >>>> by [2]. This gate breakage was held off for some time by the >>>> upper-constraints.txt file. This is great progress and I applaud it. >>>> I'll continue to cheer on this effort. >>>> >>>> Now to the next problem. If my assessment of this gate failure is >>>> correct, the update to the upper-constraints file [3] was merged >>>> without running all of the tests across all of the projects that would >>>> be broken by bringing in this new constraint. So, we still get >>>> breakage and it is still (IMO) too often. >>>> >>>> As I see it, there are a couple of options. >>>> >>>> 1) We run all tests under the upper-constraints control on all updates >>>> to the upper constraints file like [2]. This would probably mean each >>>> update has a very long list of tests and we would require that they >>>> all be fixed before the upper constraint update can be merged. This >>>> seems like a difficult thing to coordinate all at once. >>>> 2) We handle upper-constraints much like we do the global requirements >>>> updates. We have the master and a bot that proposes updates to it out >>>> to the individual projects. This would create a situation where >>>> projects are out of sync with the master but I think if we froze the >>>> master early enough, we could have time to reconcile before release. >>>> 3) We continue to allow changes in the upper constraints to break >>>> individual projects. >>>> >>>> Are there options that I missed? What is your opinion? In my >>>> opinion, gate breakage happens a bit too often and the effect on the >>>> community is widespread. I'd like to contain it even a little bit >>>> more. >>>> >>>> Carl >>>> >>>> [1] https://bugs.launchpad.net/neutron/+bug/1533638 >>>> [2] https://review.openstack.org/#/c/266885/ >>>> [3] https://review.openstack.org/#/c/266042/ >>> I've only just started to learn about requirements and constraints, so I >>> may be misunderstanding. However, >>> https://github.com/openstack/requirements/blob/master/README.rst says: >>> >>>> For upper-constraints.txt changes >>>> >>>> If the change was proposed by the OpenStack CI bot, then if the >>>> change has passed CI, only one reviewer is needed and they should +2 >>>> +A without thinking about things. >>>> >>>> If the change was not proposed by the OpenStack CI bot, and does not >>>> include a global-requirements.txt change, then it should be rejected: >>>> the CI bot will generate an appropriate change itself. Ask in >>>> #openstack-infra if the bot needs to be run more quickly. >>> Doesn't that mean that [3] should have been rejected, and hence already >>> cover the recent situation? >>> >>> Neil >>> >>> >>> __________________________________________________________________________ >>> 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 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 -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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