On Fri, Jun 19, 2015 at 3:43 PM, John Griffith <[email protected]> wrote: > Anyway, maybe I'm missing a big advantage here, but without understanding > what this gains it makes the code structure a bit hard to maintain and > follow in a number of ways. For example, in order to implement this in the > existing drivers they need to be changed to have an inheritance structure > like this: [5]. As opposed to just using the decorator which everything > would automatically propagate to any sub-class and enforce implementation > with no change or maintenance to existing drivers; but it still enforces > implementation of the required methods. > > I'd love if folks could study some of this a bit and let me know what it is > that I'm missing here. Is there some value that I'm unaware of that the > muti-inheritance paradigm in the drivers provides us?
I remember from the Kilo midcycle meetup [1] that you were part of, we discussed this accomplishing a few things: * The BaseVD represents the functionality we require from all drivers. * 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] * Any driver that wishes to mark their driver as supporting a non-required feature inherits this feature and fulfills the required methods. * 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. * Some people had thoughts of having a way generate a matrix with this information, which I dislike the idea of. Why have the middle step of having the non-required features be represented in some abc class? I guess it's a form of reference and failing sooner for not fulfilling the methods with the correct signature. This doesn't check if those methods return the right information though. So maybe it's not worth it. Marc provided a patch that would show RBD switching to this model. This revealed my main objection to the change which was the ugliness of having to inherit from all these classes, however, no one else really cared. [1] - https://etherpad.openstack.org/p/cinder-meetup-winter-2015 [2] - https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L902 -- Mike Perez __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
