[openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Hayes, Graham graham.hayes at hpe.com
Wed Aug 10 15:11:22 UTC 2016

On 10/08/2016 16:04, Ihar Hrachyshka wrote:
> Luigi Toscano <ltoscano at redhat.com> wrote:
>> On Wednesday, 10 August 2016 10:42:41 CEST Ben Swartzlander wrote:
>>> On 08/10/2016 04:33 AM, Duncan Thomas wrote:
>>>> So I tried to get into helping with the cinder stable tree for a while,
>>>> and while I wasn't very successful (lack of time and an inability to
>>>> convince my employer it should be a priority), one thing I did notice it
>>>> that much of the breakage seemed to come from outside cinder - many of
>>>> the libraries we depend on make backwards incompatible changes by
>>>> accident, for example. Would it be possible to have a long-term-support
>>>> branch where we pinned the max version of everything for the gate, pips
>>>> and devtstack? I'd have thought (and I'm very willing to be corrected)
>>>> that would make the stable gate, well, stable, such that it required far
>>>> less work to keep it able to run a basic devstack test plus unit tests.
>>>> Does that sound at all sane?
>>> A big source of problems IMO is that tempest doesn't have stable
>>> branches. We use the master branch of tempest to test stable branches of
>>> other projects, and tempest regularly adds new features. This guarantees
>>> instability if you rely on tempest anywhere in your gate (and cinder
>>> does).
>> Orthogonal to the discussion, but: this is not due to the lack of stable
>> branch, but that part of the Tempest API are not stable yet. This is being
>> addressed right now (in scope for Newton).
>> Once the Tempest stable API are used, no breakages should happen.
> Well, it’s only partially true. But what happens when you add a new test to
> tempest/master? It gets executed on all branches, and maybe some of them
> are failing it. We can argue that it’s probably a bug revealed, but it
> nevertheless requires attention from stable maintainers to solve.

And would a lot of bugs that a new test could expose be non
back-portable? AS they could cause API changes, which is banned in
the back-port policy.

Def-Core faced similar issues with new tests failing previously
validated clouds.

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

More information about the OpenStack-dev mailing list