Open Stack

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)