[openstack-dev] Further closing the holes that let gate breakage happen
davanum at gmail.com
Thu Jan 14 12:40:20 UTC 2016
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
On Thu, Jan 14, 2016 at 7:09 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
> On 14/01/16 12:01, Davanum Srinivas wrote:
>> 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.
>> -- Dims
>> On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
>>> On 13/01/16 19:27, Carl Baldwin wrote:
>>>> I was looking at the most recent gate breakage in Neutron , fixed
>>>> by . 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  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 . 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
>>>>  https://bugs.launchpad.net/neutron/+bug/1533638
>>>>  https://review.openstack.org/#/c/266885/
>>>>  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  should have been rejected, and hence already
>>> cover the recent situation?
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Davanum Srinivas :: https://twitter.com/dims
More information about the OpenStack-dev