Hey Everyone, So I've talked a little in bits and pieces regarding the implementations that are going in for the ABC metaclass work. First off, I think the use of ABC is a good idea and has value, particularly as we approach/surpass 50 third party drivers.
The only thing that I'm wondering if we could do better is the metaclass tagging of things. We have ended up with something that IMO is rather confusing and I'm not sure what the value is (perhaps this is simply a misunderstanding on my part and somebody can enlighten me). What I'm referring to is the all of the *VD classes we've created, and the fact that each driver now has an inheritance structure of multiple classes. So for example, we have a VD class for what used to be "class Driver" here: [1] It seems we could've just "left" this as "Driver" and added the abc decorators to abstract methods in the base object. Instead though we have something I don't quite understand: we have abc decorators on the methods AND we have these special meta-classes for a number of the methods. For example: [2] and [3]. What's the value here, I'm unclear on what the goal is. There is an alternative that just uses the abc decorator, and no special class designations. If you attach the abc decorator to any method in a base class, it indicates that any inheriting driver MUST implement that method. If said sub-class does NOT implement that method, the load of the module will fail. This really requires no additional code or maintenance other than just adding the decorator to the mandatory methods in the base class. There examples of what I'm describing in the target drivers [4]. 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? Thanks, John [1]: https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L247 [2]: https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L871 [3]: https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L925 [4]: https://github.com/openstack/cinder/blob/master/cinder/volume/targets/driver.py#L42 [5]: https://github.com/openstack/cinder/commit/a8030b7cb6f8199234d85d8c7574b563e5a24fe9#diff-0e51a408cd93c9e5bf454edeee2fe5c0
__________________________________________________________________________ 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
