Open Stack

On 11/08/2016 15:35, John Griffith wrote:
>
>
> On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja <ekuvaja at redhat.com
> <mailto:ekuvaja at redhat.com>> wrote:
>
>     On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis
>     <sean.mcginnis at gmx.com <mailto: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
>     <http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html>
>     >> >> [1] https://review.openstack.org/#/c/348032/
>     <https://review.openstack.org/#/c/348032/>
>     >> >> [2] https://review.openstack.org/#/c/348042/
>     <https://review.openstack.org/#/c/348042/>
>     >> >> [3]
>     https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>     <https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers>
>     >> >> [4]
>     https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
>     <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
>     <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <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).
>

Well as it currently stands, the tag should be removed.

If the policy is changed to accommodate cinder, then the tag can be
re-applied.

Personally, I think it is good how cinder deals with drivers - it means
that there is no grey area.

What we did in designate was define grades [0]. Would that be a
solution? We are planning on having the driver grade logged at startup
and if it is "Untested" or lower, logging ever increasingly large
warning messages.

Would something like this be potential solution?

I can pull out the underlying sphinx extension for displaying it if
needs be, and do a bit of tidying up.

- Graham


0 - http://docs.openstack.org/developer/designate/support-matrix.html