On 16-08-12 09:21 AM, Thierry Carrez wrote:
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.

I think building trust over time is the crucial point here. I think we as a community have learned that in certain areas, there is a vast amount of clean up to be done by allotting trust prior to it being earned.

Giving folks an opportunity to earn trust, actual trust, not just gaming a process, enables everyone to be able to work together optimally. We have learned some folks are unwilling to do the work to earn it.

But some folks are worthy of trust and have demonstrated it. Thanks to those who have wanted that for themselves.

Thank you,
Anita.


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.



__________________________________________________________________________
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

Reply via email to