<div dir="ltr"><div><div>Given the options, I'd agree with Sean and John that removing the tag is a far lesser evil than changing our policy.<br><br></div>If we leave broken drivers in the tree, the end user (operator) is no better off - the thing they evaluated won't work - but it will be harder to tell why. The storage vendor won't suffer the pressure that comes from driver removal, so will have less incentive to fix their driver (there's enough examples of the threat of driver removal causing the immediate fix of things that have remained broken for months that we know, for certain that the policy works).<br><br></div>I'd prefer to make the meaning of the tag sane WRT third party drivers, which I think would help other projects to be able to police their drivers and CI better too, without risking losing / not gaining the tag, which is likely to hurt a newer project far more than it will cinder.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 August 2016 at 17:29, John Griffith <span dir="ltr"><<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja <span dir="ltr"><<a href="mailto:ekuvaja@redhat.com" target="_blank">ekuvaja@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>> wrote:<br>
>> >><br>
>> >> As follow up on the mailing list discussion [0], gerrit activity<br>
>> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate<br>
>> >> discussion how Cinder follows, or rather does not follow, the standard<br>
>> >> deprecation policy [4] as the project has been tagged on the assert<br>
>> >> page [5].<br>
>> >><br>
> <snip><br>
>> >><br>
>> >> [0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2016-Augu<wbr>st/100717.html</a><br>
>> >> [1] <a href="https://review.openstack.org/#/c/348032/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/348032/</a><br>
>> >> [2] <a href="https://review.openstack.org/#/c/348042/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/348042/</a><br>
>> >> [3] <a href="https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers" rel="noreferrer" target="_blank">https://wiki.openstack.org/wik<wbr>i/Cinder/tested-3rdParty-drive<wbr>rs</a><br>
>> >> [4] <a href="https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/reference/tags/assert_follo<wbr>ws-standard-deprecation.html#<wbr>requirements</a><br>
>> >> [5] <a href="https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/reference/tags/assert_follo<wbr>ws-standard-deprecation.html#<wbr>application-to-current-project<wbr>s</a><br>
>> >><br>
>> ><br>
>> > Can you be more specific about what you mean? Are you saying that<br>
>> > the policy isn't being followed because the drivers were removed<br>
>> > without a deprecation period, or is there something else to it?<br>
>> ><br>
>> > Doug<br>
>> ><br>
>><br>
>> Yes, that's how I see it. Cinder's own policy is that the drivers can<br>
>> be removed without any warning to the consumers while the standard<br>
>> deprecation policy defines quite strict lines about informing the<br>
>> consumer of the functionality deprecation before it gets removed.<br>
>><br>
>> - Erno<br>
><br>
> It is a good point. I think it highlights a common thread though with<br>
> the other discussion that, at least so far, third party drivers are<br>
> treated differently than the rest of the code.<br>
><br>
> For any other functionality we certainly follow the deprecation policy.<br>
> Even in existing drivers we try to enforce that any driver renames,<br>
> config setting changes, and similar non-backwards compatible changes go<br>
> through the normal deprecation cycle before being removed.<br>
><br>
> Ideally I would love it if we could comply with the deprecation policy<br>
> with regards to driver removal. But the reality is, if we don't see that<br>
> a driver is being supported and maintained by its vendor, then that<br>
> burden can't fall on the wider OpenStack and Cinder community that has<br>
> no way of validating against physical hardware.<br>
><br>
> I think third party drivers need to be treated differently when it comes<br>
> to the deprecation policy. If that is not acceptable, then I suppose we<br>
> do need to remove that tag. Tag removal would be the lesser of the two<br>
> versus keeping around drivers that we know aren't really being<br>
> maintained.<br>
><br>
> If it came to that, I would also consider creating a new cinder-drivers<br>
> project under the Cinder umbrella and move all of the drivers not tested<br>
> by Jenkins over to that. That wouldn't be a trivial undertaking, so I<br>
> would try to avoid that if possible. But it would at least allow us to<br>
> still get code reviews and all of the benefits of being in tree. Just<br>
> some thoughts.<br>
><br>
> Sean<br>
><br>
<br>
</div></div>Sean,<br>
<br>
As said on my initial opening, I do understand and agree with the<br>
reasoning/treatment of the 3rd party drivers. My request for that tag<br>
removal is out of the remains of my ops hat.<br>
<br>
Lets say I was ops evaluating different options as storage vendor for<br>
my cloud and I get told that "Here is the list of supported drivers<br>
for different OpenStack Cinder back ends delivered by Cinder team", I<br>
start looking what the support level of those drivers are and see that<br>
Cinder follows standard deprecation which is fairly user/ops friendly<br>
with decent warning etc. I'm happy with that, not knowing OpenStack I<br>
would not even look if different subcomponents of Cinder happens to<br>
follow different policy. Now I buy storage vendor X HW and at Oct I<br>
realize that the vendor's driver is not shipped, nor any remains of it<br>
is visible anymore, I'd be reasonably pissed off. If I knew that the<br>
risk is there I would select my HW based on the negotiations that my<br>
HW is contractually tied to maintain that driver and it's CI, and that<br>
would be fine as well or if not possible I'd select some other<br>
solution I could get reasonably guarantee that it will be<br>
supported/valid at it's expected life time. As said I don't think<br>
there is anything wrong with the 3rd party driver policy, but<br>
maintaining that and the tag about standard-deprecation project wide<br>
is sending wrong message to those who do not know better to safeguard<br>
their rear ends.<br>
<br>
The other option would be to leave the drivers in tree, tag them with<br>
deprecation message, something like "This driver has not been tested<br>
by vendor CI since 15.3.2016 and cannot be guaranteed working. Unless<br>
testing will be resumed the driver will be removed on Unicorn<br>
release". Which would give as clear indication that the driver seems<br>
abandoned, but still provide the consumer easier way to test in their<br>
staging if the driver is something they still dare to use in<br>
production or not.<br>
<br>
IMHO this is purely to set the expectations right for our consumers so<br>
that they know what to expect from us and what to demand from their<br>
vendors. Personally I don't think such tags should be the reason why<br>
we do development in certain way, but rather just indication for the<br>
consumer where they should pay attention while making the decisions.<br>
<span><font color="#888888"><br>
- Erno<br>
</font></span><div><div><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><span style="color:rgb(80,0,80)">>> Yes, that's how I see it. Cinder's own policy is that the drivers can</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">>> be removed without any warning to the consumers while the standard</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">>> deprecation policy defines quite strict lines about informing the</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">>> consumer of the functionality deprecation before it gets removed.</span><br></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div></span></div></div></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">That is a great point, it was mentioned at one point but we sort of conveniently swept it under the rug a bit.  I certainly understand the problem, I do think there's two sides to it.  Frankly I also think it points out that drivers really are *different* like it or not.​  So it totally sucks that yes, a release could come out and that driver no longer exists, and that's no good.</div><br></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">BUT on the other hand, it's not much worse to find that the code has been all but abandoned and no longer works anyway.  I don't think either scenario is a good one.  It highlights in my opinion that frankly maybe distros and customers should be more selective in what they choose to use.  Community involvement matters.</div></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">That being said, I'm not sure which I'd prefer to see happen in this situation.  I lean slightly towards remove the "follows deprecation" tag from Cinder and continue to remove drivers.  </div></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">The alternative isn't much better, but if we go that route I do think we should come up with some widely broadcasted advertisement of drivers that are just using Cinder as dumping ground and don't offer any care and feeding to the project in any way shape or form (you know who you are... but you're not reading this ML anyway).</div></span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></span></div></div>
<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><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div>