<div dir="ltr"><br><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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br></div></div>
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></blockquote><div><br></div><div>Can we clarify if anyone is aware of this *actually* happening?    Because this description of events sounds *terrible*?  If we have a case-in-point I think it'd be down right negligent to not give the situation a proper RCA, but I'd be *real* curious to hear the previous "4 whys" that lead to "ultimately; the problems was the tags..."</div><div><br></div><div>I'm much more inclined to think that we should trust the Cinder team to do what they think is best based on their experience.  If their experience is that it's better for their operators that they *not* ship "deprecated (but probably broken)" drivers - GOOD FOR THEM!  I think it'd be great if the "standard deprecation policy" can be informed and updated based on the experience of a successful project like Cinder - if not, yeah I really hope they continue to do the *right* thing over the *standard* thing.</div><div><br></div><div>OTOH, if what they think is right is causing *real* problems, let's surface those - if they got to this policy based on experience, new information will spur new ideas.  But that's different than some pontification based on hypotheticals.  Speaking of which, why is this even coming up in the *development* ML?</div><div><br></div><div>-Clay</div></div></div></div>