<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hey Everyone,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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]</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">There examples of what I'm describing in the target drivers [4].</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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?  </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L247">https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L247</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[2]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L871">https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L871</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[3]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L925">https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L925</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[4]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/targets/driver.py#L42">https://github.com/openstack/cinder/blob/master/cinder/volume/targets/driver.py#L42</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[5]: <a href="https://github.com/openstack/cinder/commit/a8030b7cb6f8199234d85d8c7574b563e5a24fe9#diff-0e51a408cd93c9e5bf454edeee2fe5c0">https://github.com/openstack/cinder/commit/a8030b7cb6f8199234d85d8c7574b563e5a24fe9#diff-0e51a408cd93c9e5bf454edeee2fe5c0</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div>