<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 12, 2016 at 7:37 AM, Sean McGinnis <span dir="ltr"><<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</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 Fri, Aug 12, 2016 at 03:40:47PM +0300, Duncan Thomas wrote:<br>
> On 12 Aug 2016 15:28, "Thierry Carrez" <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
> ><br>
> > Duncan Thomas wrote:<br>
><br>
> > I agree that leaving broken drivers in tree is not significantly better<br>
> > from an operational perspective. But I think the best operational<br>
> > experience would be to have an idea of how much risk you expose yourself<br>
> > when you pick a driver, and have a number of them that are actually<br>
> > /covered/ by the standard deprecation policy.<br>
> ><br>
> > So ideally there would be a number of in-tree drivers (on which the<br>
> > Cinder team would apply the standard deprecation policy), and a separate<br>
> > repository for 3rd-party drivers that can be removed at any time (and<br>
> > which would /not/ have the follows-standard-deprecation-<wbr>policy tag).<br>
><br>
> So we'd certainly have to move out all of the backends requiring<br>
> proprietary hardware, since we couldn't commit to keeping them working if<br>
> their vendors turn of their CI. That leaves ceph, lvm, NFS, drdb, and<br>
> sheepdog, I think. There is not enough broad knowledge in the core team<br>
> currently to support sheepdog or drdb without 'vendor' help. That would<br>
> leave us with three drivers in the tree, and not actually provide much<br>
> useful risk information to deployers at all.<br>
><br>
> > I understand that this kind of reorganization is a bit painful for<br>
> > little (developer-side) gain, but I think it would provide the most<br>
> > useful information to our users and therefore the best operational<br>
> > experience...<br>
><br>
> In theory this might be true, but see above - in practice it doesn't work<br>
> that way.<br>
<br>
</div></div>I was leaning towards a separate repo until I started thinking about all<br>
the overhead and complications this would cause. It's another repo for<br>
cores to watch. It would cause everyone extra complication in setting up<br>
their CI, which is already one of the biggest roadblocks. It would make<br>
it a little harder to do things like <a href="https://review.openstack.org/297140" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>297140</a><br>
and <a href="https://review.openstack.org/346470" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>346470</a> to be able to generate this:<br>
<a href="http://docs.openstack.org/developer/cinder/drivers.html" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>developer/cinder/drivers.html</a>. Plus more infra<br>
setup, more moving parts to break, and just generally more<br>
complications.<br>
<br>
All things that can be solved for sure. I just question whether it would<br>
be worth having that overhead. Frankly, there are better things I'd like<br>
to spend my time on.<br>
<br>
I think at this point my first preference would actually be to define a<br>
new tag. This addresses both the driver removal issue as well as the<br>
backporting of driver bug fixes. I would like to see third party drivers<br>
recognized and treated as being different, because in reality they are<br>
very different than the rest of the code. Having something like<br>
follows_deprecation_but_has_<wbr>third_party_drivers_that_dont would make a<br>
clear statement that their is a vendor component to this project that<br>
really has to be treated differently and has different concerns<br>
deployers need to be aware of.<br>
<br>
Barring that, I think my next choice would be to remove the tag. That<br>
would really be unfortunate as we do want to make it clear to users that<br>
Cinder will not arbitrarily break APIs or do anything between releases<br>
without warning when it comes to non-third party drivers. But if that is<br>
what we need to do to effectively communicate what to expect from<br>
Cinder, then I'm OK with that.<br>
<br>
My last choice (of the ones I'm favorable towards) would be marking a<br>
driver as untested/unstable/abandoned/<wbr>etc rather than removing it. We<br>
could flag these a certain way and have then spam the logs like crazy<br>
after upgrade to make it very and painfully clear that they are not<br>
being maintained. But as Duncan pointed out, this doesn't have as much<br>
impact for getting vendor attention. It's amazing the level of executive<br>
involvement that can happen after a patch is put up for driver removal<br>
due to non-compliance.<br>
<span class="HOEnZb"><font color="#888888"><br>
Sean<br>
</font></span><div class="HOEnZb"><div class="h5"><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></div></div></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Yeah, I think something like a "passes-upstream-integration" tag per driver would be a better option.  Whether that's collected via automation looking at the gerrit info from 3'rd party CI or we bring back the old manual Cert scripts (or some form of them) is another conversation worth having next time we're all together.​  Now to try and agree on the criteria might be a bit of work.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><div><font face="monospace, monospace"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">By going with a tag we don't remove anything but we also don't pretend that we know it works or anything either.  </div></font></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> <span style="font-family:monospace,monospace">The statement suggesting that if it's not in the infra gate then it must be considered as maybe not there in the future obviously isn't a good thing.  Probably shouldn't forget that it wasn't that long ago that LVM was the only driver in the gate and probably still should be depending on who you ask.  Anyway, I'd hope that nobody would twist that around and try and capitalize on it but who knows.</span></div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Anyway... there's a TON of improvement to be had around how we're doing this stuff in Cinder in my opinion.  I'm really mostly convinced that 3'rd party CI has been a failure and I don't see that changing.  Failure is a good thing by the way, assuming you learn from it.  The only project that has similar problems to solve is Neutron so maybe some collaboration between the two projects again here would be good.  I've also tried to engage the Distros (their Cinder counterparts) on topics like this, stable-branches etc but it doesn't seem they're as interested as I thought on these topics.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Keep in mind for those that don't know, each OpenStack vendor requires that each Cinder driver run through their own set of qualification and cert integrations upon each release.  The only environments our conversations really effect are those that don't use a commercial OpenStack Distro, granted in some views those are the ones that matter most.</div><div class="gmail_default" style="font-family:monospace,monospace"> </div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div></div>