[openstack-dev] Further closing the holes that let gate breakage happen
Davanum Srinivas
davanum at gmail.com
Thu Jan 14 11:58:59 UTC 2016
Neil,
The global requirements upper-constraints.txt do not cover neutron
unit test targets. So the unit tests pick up latest from pypi.
-- 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:
>> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: https://twitter.com/dims
More information about the OpenStack-dev
mailing list