Open Stack

On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja <ekuvaja at redhat.com> wrote:

> On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis <sean.mcginnis at gmx.com>
> wrote:
> >> >>
> >> >> As follow up on the mailing list discussion [0], gerrit activity
> >> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> >> discussion how Cinder follows, or rather does not follow, the
> standard
> >> >> deprecation policy [4] as the project has been tagged on the assert
> >> >> page [5].
> >> >>
> > <snip>
> >> >>
> >> >> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/100717.html
> >> >> [1] https://review.openstack.org/#/c/348032/
> >> >> [2] https://review.openstack.org/#/c/348042/
> >> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> >> >> [4] https://governance.openstack.org/reference/tags/assert_
> follows-standard-deprecation.html#requirements
> >> >> [5] https://governance.openstack.org/reference/tags/assert_
> follows-standard-deprecation.html#application-to-current-projects
> >> >>
> >> >
> >> > Can you be more specific about what you mean? Are you saying that
> >> > the policy isn't being followed because the drivers were removed
> >> > without a deprecation period, or is there something else to it?
> >> >
> >> > Doug
> >> >
> >>
> >> Yes, that's how I see it. Cinder's own policy is that the drivers can
> >> be removed without any warning to the consumers while the standard
> >> deprecation policy defines quite strict lines about informing the
> >> consumer of the functionality deprecation before it gets removed.
> >>
> >> - Erno
> >
> > It is a good point. I think it highlights a common thread though with
> > the other discussion that, at least so far, third party drivers are
> > treated differently than the rest of the code.
> >
> > For any other functionality we certainly follow the deprecation policy.
> > Even in existing drivers we try to enforce that any driver renames,
> > config setting changes, and similar non-backwards compatible changes go
> > through the normal deprecation cycle before being removed.
> >
> > Ideally I would love it if we could comply with the deprecation policy
> > with regards to driver removal. But the reality is, if we don't see that
> > a driver is being supported and maintained by its vendor, then that
> > burden can't fall on the wider OpenStack and Cinder community that has
> > no way of validating against physical hardware.
> >
> > I think third party drivers need to be treated differently when it comes
> > to the deprecation policy. If that is not acceptable, then I suppose we
> > do need to remove that tag. Tag removal would be the lesser of the two
> > versus keeping around drivers that we know aren't really being
> > maintained.
> >
> > If it came to that, I would also consider creating a new cinder-drivers
> > project under the Cinder umbrella and move all of the drivers not tested
> > by Jenkins over to that. That wouldn't be a trivial undertaking, so I
> > would try to avoid that if possible. But it would at least allow us to
> > still get code reviews and all of the benefits of being in tree. Just
> > some thoughts.
> >
> > Sean
> >
>
> Sean,
>
> As said on my initial opening, I do understand and agree with the
> reasoning/treatment of the 3rd party drivers. My request for that tag
> removal is out of the remains of my ops hat.
>
> Lets say I was ops evaluating different options as storage vendor for
> my cloud and I get told that "Here is the list of supported drivers
> for different OpenStack Cinder back ends delivered by Cinder team", I
> start looking what the support level of those drivers are and see that
> Cinder follows standard deprecation which is fairly user/ops friendly
> with decent warning etc. I'm happy with that, not knowing OpenStack I
> would not even look if different subcomponents of Cinder happens to
> follow different policy. Now I buy storage vendor X HW and at Oct I
> realize that the vendor's driver is not shipped, nor any remains of it
> is visible anymore, I'd be reasonably pissed off. If I knew that the
> risk is there I would select my HW based on the negotiations that my
> HW is contractually tied to maintain that driver and it's CI, and that
> would be fine as well or if not possible I'd select some other
> solution I could get reasonably guarantee that it will be
> supported/valid at it's expected life time. As said I don't think
> there is anything wrong with the 3rd party driver policy, but
> maintaining that and the tag about standard-deprecation project wide
> is sending wrong message to those who do not know better to safeguard
> their rear ends.
>
> The other option would be to leave the drivers in tree, tag them with
> deprecation message, something like "This driver has not been tested
> by vendor CI since 15.3.2016 and cannot be guaranteed working. Unless
> testing will be resumed the driver will be removed on Unicorn
> release". Which would give as clear indication that the driver seems
> abandoned, but still provide the consumer easier way to test in their
> staging if the driver is something they still dare to use in
> production or not.
>
> IMHO this is purely to set the expectations right for our consumers so
> that they know what to expect from us and what to demand from their
> vendors. Personally I don't think such tags should be the reason why
> we do development in certain way, but rather just indication for the
> consumer where they should pay attention while making the decisions.
>
> - Erno
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

>> Yes, that's how I see it. Cinder's own policy is that the drivers can
>> be removed without any warning to the consumers while the standard
>> deprecation policy defines quite strict lines about informing the
>> consumer of the functionality deprecation before it gets removed.
​
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.


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.

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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160811/ac83c4b3/attachment.html>