Open Stack

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.
>