On 08/12/2016 08:40 AM, Duncan Thomas wrote:
> On 12 Aug 2016 15:28, "Thierry Carrez" <thie...@openstack.org
> <mailto:thie...@openstack.org>> wrote:
>>
>> Duncan Thomas wrote:
>
>> I agree that leaving broken drivers in tree is not significantly better
>> from an operational perspective. But I think the best operational
>> experience would be to have an idea of how much risk you expose yourself
>> when you pick a driver, and have a number of them that are actually
>> /covered/ by the standard deprecation policy.
>>
>> So ideally there would be a number of in-tree drivers (on which the
>> Cinder team would apply the standard deprecation policy), and a separate
>> repository for 3rd-party drivers that can be removed at any time (and
>> which would /not/ have the follows-standard-deprecation-policy tag).
>
> So we'd certainly have to move out all of the backends requiring
> proprietary hardware, since we couldn't commit to keeping them working
> if their vendors turn of their CI. That leaves ceph, lvm, NFS, drdb, and
> sheepdog, I think. There is not enough broad knowledge in the core team
> currently to support sheepdog or drdb without 'vendor' help. That would
> leave us with three drivers in the tree, and not actually provide much
> useful risk information to deployers at all.
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".
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
