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 <t...@bakeyournoodle.com
<mailto:t...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
