[openstack-dev] [Cinder] Implementation of ABC MetaClasses

John Griffith john.griffith8 at gmail.com
Fri Jun 19 22:43:02 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150619/33a24cc0/attachment.html>


More information about the OpenStack-dev mailing list