[openstack-dev] Further closing the holes that let gate breakage happen
Neil.Jerram at metaswitch.com
Thu Jan 14 11:51:50 UTC 2016
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,
> 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?
More information about the OpenStack-dev