Open Stack

On Fri, Jun 19, 2015 at 3:43 PM, John Griffith <john.griffith8 at gmail.com> 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