Open Stack

Am 20.06.2015 um 01:59 schrieb John Griffith <john.griffith8 at gmail.com>:
> * The BaseVD represents the functionality we require from all drivers.
> ​Yep
> ​ 
> * The additional ABC classes represent features that are not required yet.
>   * These are represented by classes because some features require a
> bundle of methods for it to be fulfilled. Consistency group is an
> example. [2]
> 
> ​Sure, I suppose that's fine for things like CG and Replication.  Although I would think that if somebody implemented something optional like CG's that they should be able to figure out they need all of the "cg" methods, it's kinda like that warning on ladders to not stand on the very top rung.  By the way, maybe we should discuss the state of "optional API methods" at the mid-cycle.
>  
>   * Any driver that wishes to mark their driver as supporting a
> non-required feature inherits this feature and fulfills the required
> methods.
> 
> ​Yeah... ok​, I guess.
> 
> * After communication is done on said feature being required, there
> would be time for driver maintainers to begin supporting it.
>   * Eventually that feature would disappear from it's own class and be
> put in the BaseVD. Anybody not supporting it would have a broken
> driver, a broken CI, and eventually removed from the release.
> 
> ​Sure, I guess my question is what's the real value in this intermediate step.  The bulk of these are things that I'd argue shouldn't be optional anyway (snapshots, transfers, manage, extend, retype and even migrate).  Snapshots in particular I find surprising to be considered as "optional“.

Reducing the number of classes/optional functions sounds good to me.
I think it’s quite valuable to discuss what are the mandatory functions
of a cinder driver. Before ABC nobody really cared because all drivers simply raised an run-time exception :)

> ​ 
> * Some people had thoughts of having a way generate a matrix with this
> information, which I dislike the idea of.
> 
> ​Yeah, back to the dreaded "Matrix", I can't imagine anything worse for Cinder than a matrix of supported API calls on a driver per driver basis.​ 

I agree that such a matrix tool isn’t the finial goal.
But it helps to see which functions are already "common“ and which are "optional“.
Just try it [1] ;)

Regards
Marc

[1]: https://review.openstack.org/#/c/160346/
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev