Open Stack

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

-Ben Swartzlander


> (I'm aware there are community standards for stable currently, but a lot
> of this thread is the tail of standards wagging the dog of our goals.
> Lets figure out what we want to achieve, and figure out how we can do
> that without causing either too much extra work or an unnecessary fall
> off in quality, rather than saying we can't do anything because of how
> we do things now.)
>
>
>
>
> On 10 August 2016 at 08:54, Tony Breeds <tony at bakeyournoodle.com
> <mailto:tony at bakeyournoodle.com>> wrote:
>
>     On Tue, Aug 09, 2016 at 09:16:02PM -0700, John Griffith wrote:
>     > Sorry, I wasn't a part of the sessions in Austin on the topic of long
>     > terms support of Cinder drivers.  There's a lot going on during the summits
>     > these days.
>
>     For the record the session in Austin, that I think Matt was
>     referencing,  were
>     about stable life-cycles. not cinder specific.
>
>     > Yeah, ok... I do see your point here, and as I mentioned I have had this
>     > conversation with you and others over he years and I don't
>     disagree.  I also don't have the ability to "force"
>     > said parties to do things differently.  So when I try and help customers
>     > that are having issues my only recourse is an out of tree patch, which then
>     > when said distro notices or finds out they don't want to support the
>     > customer any longer based on the code no longer being "their blessed
>     > code".  The fact is that the distros hold the power in these situations, if
>     > they happen to own the OS release and the storage then it works out great
>     > for them, not so much for anybody else.​
>
>     Right we can't 'force' the distros to participate (if we could we
>     wouldn't be
>     having this discussion).  The community has a process and all we can
>     do is
>     encourage distros and the like to participate in that process as it
>     really is
>     best for them, and us.
>
>     > So is the consensus here that the only viable solution is for people to
>     > invest in keeping the stable branches in general supported longer?  How
>     > does that work for projects that are interested and have people willing to
>     > do the work vs projects that don't have the people willing to do the work?
>     > In other words, Cinder has a somewhat unique problem that Nova, Glance and
>     > Keystone don't have.  So for Cinder to try and follow the policies,
>     > processes and philosophies you outlined does that mean that as a project
>     > Cinder has to try and bend the will of "ALL" of the projects to make this
>     > happen?  Doesn't seem very realistic to me.​
>
>     So the 'Cinder' team wont need to do all the will bending, that's
>     for the
>     Stable team to do with the support of *everyone* that cares about
>     the outcome.
>     That probably doens't fill you with hope, but that is the reality.
>
>     > Just one last point and I'll move on from the topic.  I'm not sure where
>     > this illusion that we're testing all the drivers so well is coming from.
>     > Sure, we require the steps and facade of 3'rd party CI, but dig a bit
>     > deeper and you soon find that we're not really testing as much as some
>     > might think here.
>
>     That's probbaly true but if we created a 'mitaka-drivers' branch of
>     cinder the
>     gate CI would rapidly degernate to a noop any unit/functional tests
>     would be
>     *entirely* 3rd party.
>
>     Yours Tony.
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> --
> --
> Duncan Thomas
>
>
> __________________________________________________________________________
> 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
>