Open Stack

On 14 November 2015 at 02:53, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> Hi Sachi and all,
>
> I was recently looking into how stable/liberty branches are set for neutron
> in terms of requirements caps, and I realized that we don’t have neither
> version caps nor upper constraints applied to unit test jobs in
> stable/liberty gate. We have -constraints targets defined in tox.ini, but
> they are not running in gate.
>
> I believe this situation leaves us open to breakages by any random library
> releases out there. Am I right? If so, I would like to close the breakage
> vector for projects I care (all neutron stadium).
>
> I suggest we do the following:
>
> - unless there is some specific reason for that, stop running unconstrained
> jobs in neutron/master;

Sachi King is working up a bit of data mining to confirm that the
constraints jobs are only failing when unconstrained jobs fail - then
we're going to propose the change to project-config to switch around
which vote.

> - enable voting for constraints jobs in neutron/liberty; once proved to work
> fine, stop running unconstrained jobs in neutron/liberty;

I expect the same query can answer this as well.

> - for neutron-*aas, introduce constraints targets in tox.ini, enable jobs in
> gate; make them vote there/remove old jobs;
> - after that, backport constraints targets to stable/liberty; make them vote
> there/remove old jobs.

We're going to advocate widespread adoption once the neutron master
ones are voting

> Does the plan make sense?

Totally :) As non-Neutron-contributors we've just been conservative in
our recommendations; if Neutron wants to move a little faster by
taking on a little risk, thats *totally cool* IMO.

-Rob

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