Sean Dague wrote: > I 100% understand the cinder policy of kicking drivers out without CI. > And I think there is a lot of value in ensuring what's in tree is tested. > > However, from a user perspective basically it means that if you deploy > Newton cinder and build a storage infrastructure around anything other > than ceph, lvm, or NFS, you have a very real chance of never being able > to upgrade to Ocata, because your driver was fully deleted, unless you > are willing to completely change up your storage architecture during the > upgrade. > > That is the kind of reality that should be front and center to the > users. Because it's not just a drop of standard deprecation, it's also a > removal of 'supports upgrade', as Netwon cinder config won't work with > Ocata. > > Could there be more of an off ramp / on ramp here to the drivers? If a > driver CI fails to meet the reporting window mark it deprecated for the > next delete window. If a driver is in a deprecated state they need some > long window of continuous reporting to get out of that state (like 120 > days or something). Bring in all new drivers in a > deprecated/experimental/untested state, which they only get to shrug off > after the onramp window? > > It's definitely important that the project has the ability to clean out > the cruft, but it would be nice to not be overly brutal to our operators > at the same time. > > And if not, I think that tags (or lack there of) aren't fully > communicating the situation here. Cinder docs should basically say "only > use ceph / lvm / nfs, as those are the only drivers that we can > guarantee will be in the next release".
+1 Both of the options (keeping cruft in tree vs. having no assurance at all that your choice of driver will be around in 6 months) are horrible from an operators standpoint. But I think that's a false dichotomy and we need a more subtle solution: communicate about sane drivers where we trust the ability of core team or the vendor to still provide a workable solution in the next release (following standard deprecation policy) while still being able to remove cruft if a driver goes stale / untested. That means defining multiple tiers of trust, and having each driver build that trust over time. In that other thread I proposed two tiers (in openstack/cinder following deprecation and stable policies and in a separate Cinder repository if you don't trust it to follow the policies) since the Cinder team sees value in keeping them cinder-core-reviewed and in a limited number of repositories. -- Thierry Carrez (ttx) __________________________________________________________________________ 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
