Am 20.06.2015 um 01:59 schrieb John Griffith <john.griffi...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
