On 11/08/2016 15:35, John Griffith wrote: > > > On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja <ekuv...@redhat.com > <mailto:ekuv...@redhat.com>> wrote: > > On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis > <sean.mcgin...@gmx.com <mailto:sean.mcgin...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev