Open Stack

On 14 January 2016 at 08:24, Carl Baldwin <carl at ecbaldwin.net> 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.

We don't need to run 100% of tests to have good coverage - breakage
mitigation is probabalistic, and I think always will be - its the
combination of far too many interacting variables to be otherwise.

We tried to add some unit test jobs to cross check constraints, but we
need some infrastructure work to permit specifying that a unit test
job for a change to requirements checkout the code for e.g. nova and
run nova's tests. Jeremy has more info on that :).

> 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.

Part of the fundamental design of constraints is that its a single
point of control - so we can fix it with a single commit.

> 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/
>
> __________________________________________________________________________
> 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



-- 
Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud