Open Stack

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?

(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> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160810/2cf5b553/attachment.html>