<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 9, 2016 at 10:26 PM, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Aug 09, 2016 at 09:16:02PM -0700, John Griffith wrote:<br>
> On Tue, Aug 9, 2016 at 7:21 PM, Matthew Treinish <<a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a>><br>
> wrote:<br>
><br>
> > On Tue, Aug 09, 2016 at 05:28:52PM -0700, John Griffith wrote:<br>
> > > On Tue, Aug 9, 2016 at 4:53 PM, Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>><br>
> > wrote:<br>
> > ><br>
> > > > .<br>
> > > > ><br>
> > > > > Mike, you must have left the midcycle by the time this topic came<br>
> > > > > up. On the issue of out-of-tree drivers, I specifically offered this<br>
> > > > > proposal (a community managed mechanism for distributing driver<br>
> > > > > bugfix backports) as an compromise alternative to try to address the<br>
> > > > > needs of both camps. Everyone who was in the room at the time (plus<br>
> > > > > DuncanT who wasn't) agreed that if we had that (a way to deal with<br>
> > > > > backports) that they wouldn't want drivers out of the tree anymore.<br>
> > > > ><br>
> > > > > Your point of view wasn't represented so go ahead and explain why,<br>
> > > > > if we did have a reasonable way for bugfixes to get backported to<br>
> > > > > the releases customers actually run (leaving that mechanism<br>
> > > > > unspecified for the time being), that you would still want the<br>
> > > > > drivers out of the tree.<br>
> > > > ><br>
> > > > > -Ben Swartzlander<br>
> > > ><br>
> > > > The conversation about this started around the 30 minute point here if<br>
> > > > anyone is interested in more of the background discussion on this:<br>
> > > ><br>
> > > > <a href="https://www.youtube.com/watch?v=g3MEDFp08t4" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=g3MEDFp08t4</a><br>
> > > ><br>
> > > > ______________________________<wbr>______________________________<br>
> > ______________<br>
> > > > OpenStack Development Mailing List (not for usage questions)<br>
> > > > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject</a>:<br>
> > unsubscribe<br>
> > > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> > > ><br>
> > ><br>
> > > ​I don't think anybody is whining at all here, we had a fairly productive<br>
> > > discussion at the mid-cycle surrounding this topic and I do think there<br>
> > are<br>
> > > some valid advantages to this approach regardless of the QA question.<br>
> > Note<br>
> > > that it's been pointed out we weren't talking about or considering<br>
> > > advertising this *special* branch as tested by the standard means or gate<br>
> > > CI etc.<br>
> > ><br>
> > > We did discuss this though mostly in the context of helping the package<br>
> > > maintainers and distributions.  The fact is that many of us currently<br>
> > offer<br>
> > > backports of fixes in our own various github accounts.  That's fine and<br>
> > it<br>
> > > works well for many.  The problem we were trying to address however is<br>
> > that<br>
> > > this practice is rather problematic for the distros.  For example RHEL,<br>
> > > Helion or Mirantis are most certainly not going to run around cherry<br>
> > > picking change sets from random github repos scattered around.<br>
> > ><br>
> > > The context of the discussion was that by having a long lived *driver*<br>
> > > (emphasis on driver) branch there would be a single location and an<br>
> > *easy*<br>
> > > method of contact and communication regarding fixes to drivers that may<br>
> > be<br>
> > > available for stable branches that are no longer supported.  This puts<br>
> > the<br>
> > > burden of QA/Testing mostly on the vendors and distros, which I think is<br>
> > > fine.  They can either choose to work with the Vendor and verify the<br>
> > > versions for backport on a regular basis, or they can choose to ignore<br>
> > them<br>
> > > and NOT provide them to their customers.<br>
> > ><br>
> > > I don't think this is an awful idea, and it's very far from the "drivers<br>
> > > out of tree" discussion.  The feedback from the distro maintainers during<br>
> > > the week was that they would gladly welcome a model where they could pull<br>
> > > updates from a single driver branch on a regular basis or as needed for<br>
> > > customers that are on *unsupported* releases and for whom a fix exists.<br>
> > > Note that support cycles are not the same for the distros as they are of<br>
> > > the upstream community.  This is in no way proposing a change to the<br>
> > > existing support time frames or processes we have now, and in that way it<br>
> > > differs significantly from proposals and discussions we've had in the<br>
> > past.<br>
> > ><br>
> > > The basic idea here was to eliminate the proliferation of custom backport<br>
> > > patches scattered all over the web, and to ease the burden for distros<br>
> > and<br>
> > > vendors in supporting their customers.  I think there may be some<br>
> > concepts<br>
> > > to iron out and I certainly understand some of the comments regarding<br>
> > being<br>
> > > disingenuous regarding what we're advertising.  I think that's a<br>
> > > misunderstanding of the intent however, the proposal is not to extend the<br>
> > > support life of stable from an upstream or community perspective but<br>
> > > instead the proposal is geared at consolidation and tracking of drivers.<br>
> ><br>
> > I fully understood the proposal but I still think you're optimizing for the<br>
> > wrong thing.<br>
><br>
> ​Ok, that's fair. It seemed like there might be some confusion with some of<br>
> the comments that were made.<br>
>  ​<br>
><br>
><br>
> > We have a community process for doing backports and maintaining<br>
> > released versions of OpenStack code. The fundamental problem here is<br>
> > actually<br>
> > that the parties you've identified aren't actively involved in stable<br>
> > branch<br>
> > maintenance.<br>
><br>
> ​Yes, I know that I've had this conversation with you as well as a few<br>
> others on the infra team over the past year or so.<br>
> ​<br>
><br>
><br>
> > The stable maint team and policy was primarily created as a<br>
> > solution to the exact problem you outlined above, that it providing a<br>
> > place for<br>
> > vendors, distros, etc to collaborate on backports and stable branch maint.<br>
> > while following our communities process. Regardless of framing it as being<br>
> > only<br>
> > for drivers it doesn't change that you're talking about the same thing.<br>
> > (this is<br>
> > why in-tree vs out-of-tree was coming up from others, because if it was<br>
> > out-of-tree then you don't have to respect the stable policy)<br>
> ><br>
> ​I don't necessarily fully agree on your statement, I certainly see your<br>
> perspective and can't give an argument to counter it but just that I do see<br>
> a different perspective here as well.  It's not quite so black and white to<br>
> me.  As far as the out of tree comments, I'm not even going to justify<br>
> parts of that thread with a response here.<br>
><br>
> ><br>
> > What I was getting at before was if instead of ignoring all the previous<br>
> > conversations we've had about this exact topic (including 2 sessions in<br>
> > Austin)<br>
> ><br>
> ​Sorry, I wasn't a part of the sessions in Austin on the topic of long<br>
> terms support of Cinder drivers.  There's a lot going on during the summits<br>
> these days.<br>
> ​<br>
<br>
</div></div>FWIW, it wasn't just cinder drivers, it was long term support of stable branches,<br>
which includes cinder drivers. Heh, but yeah I can understand that, there is<br>
definitely a lot going on at summit.<br>
<div><div class="h5"><br>
><br>
><br>
> > and people actually stepped up and got involved we wouldn't be having this<br>
> > discussion today. More than likely we'd have enough people to actually<br>
> > maintain<br>
> > a stable branch for longer than we can today. But, instead it feels like<br>
> > our<br>
> > community process for code review and actually testing proposed backports<br>
> > is too<br>
> > much of a burden for any of these parties you've identified to bother<br>
> > getting<br>
> > involved. So we're instead in a situation where we have a proposal to<br>
> > actively<br>
> > circumvent our community policy and procedures for maintaining stable<br>
> > branches.<br>
> ><br>
> ​Yeah, ok... I do see your point here, and as I mentioned I have had this<br>
> conversation with you and others over​<br>
><br>
> ​the years and I don't disagree.  I also don't have the ability to "force"<br>
> said parties to do things differently.  So when I try and help customers<br>
> that are having issues my only recourse is an out of tree patch, which then<br>
> when said distro notices or finds out they don't want to support the<br>
> customer any longer based on the code no longer being "their blessed<br>
> code".  The fact is that the distros hold the power in these situations, if<br>
> they happen to own the OS release and the storage then it works out great<br>
> for them, not so much for anybody else.​<br>
><br>
> ><br>
> > Creating a free space where vendors can push whatever they want without any<br>
> > gating is not only contrary to our stable branch policy but also goes<br>
> > against<br>
> > some of the fundamental tenants of OpenStack. It's not something I think we<br>
> > should ever be doing.<br>
> ><br>
> ​Not quite sure I agree with that.  We have quite a bit of code that isn't<br>
> gated against, and for years had entire modules and configs that were never<br>
> gated.  I'm not saying that makes it right, or that it's good; but I don't<br>
> think it's quite as dire as it's made out here.​<br>
><br>
><br>
> ><br>
> > ><br>
> > > If this isn't something we can come to an agreement on as a community,<br>
> > then<br>
> > > I'd suggest we just create our own repo on github outside of upstream and<br>
> > > have it serve the same purpose.<br>
> > ><br>
> ><br>
> > If you're dead set on doing this then I think that's your only recourse,<br>
> > because<br>
> > what you're attempting to do is something outside our community processes<br>
> > and<br>
> > I don't think it has any place in upstream. But, I really think it'd be<br>
> > much<br>
> > better if instead of going off into a corner that all of the people who<br>
> > have<br>
> > complained about the state of our current stable support windows and stable<br>
> > policy actually got involved in this space. That way over time we can make<br>
> > the stable branches something where we can have longer support windows.<br>
> ><br>
> ​I'm certainly not dead set on this, I was hoping that maybe there could be<br>
> some constructive discussion not scolding.<br>
><br>
> Yes, in a perfect world we'd have teams that did in fact keep branches<br>
> around longer.  Even then I'm not sure it's realistic.  Things are getting<br>
> better, but traditionally when the distros release updates a year after the<br>
> community does you sort of end up in a pretty crappy position.  Like I<br>
> said, this is getting way better, and who knows... things are catching up<br>
> enough these days that maybe this won't even be an issue any longer in<br>
> another 6 months to  year.<br>
><br>
><br>
> ​So is the consensus here that the only viable solution is for people to<br>
> invest in keeping the stable branches in general supported longer?  How<br>
> does that work for projects that are interested and have people willing to<br>
> do the work vs projects that don't have the people willing to do the work?<br>
> In other words, Cinder has a somewhat unique problem that Nova, Glance and<br>
> Keystone don't have.  So for Cinder to try and follow the policies,<br>
> processes and philosophies you outlined does that mean that as a project<br>
> Cinder has to try and bend the will of "ALL" of the projects to make this<br>
> happen?  Doesn't seem very realistic to me.​<br>
><br>
> Just one last point and I'll move on from the topic.  I'm not sure where<br>
> this illusion that we're testing all the drivers so well is coming from.<br>
> Sure, we require the steps and facade of 3'rd party CI, but dig a bit<br>
> deeper and you soon find that we're not really testing as much as some<br>
> might think here.<br>
<br>
</div></div>I never said our testing coverage was good here, believe me I have no illusions<br>
about that. But, the proposal in this thread would result in having zero testing<br>
in the upstream CI system after we EOL of branch. The infrastructure just<br>
wouldn't be there anymore. It's that point I have a very big issue with, even if<br>
the quality of testing that we would not be running anymore is far from ideal<br>
and mostly just pro forma. What I see as the problem with that is that it means<br>
we would never even try to execute (or install) the code once in the OpenStack<br>
CI before we merge it, despite being part of an OpenStack project. That is what<br>
I see as being contrary to our community standards for doing development.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Yes, I agree it sucks; I would like to push the burden of said testing of those drivers back on to the distros.  I do agree though that ideally the right answer is to push overall care and feeding of stable to keep it around longer.</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Matt Treinish<br>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>