Open Stack

Am 08.07.2015 um 01:37 schrieb Mike Perez <thingee at gmail.com>:

> On 18:38 Jun 22, Marc Koderer wrote:
>> 
>> Am 20.06.2015 um 01:59 schrieb John Griffith <john.griffith8 at gmail.com>:
>>> * The BaseVD represents the functionality we require from all drivers.
>>> ​Yep
>>> ​ 
>>> * 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]
>>> 
>>> ​Sure, I suppose that's fine for things like CG and Replication.  Although I would think that if somebody implemented something optional like CG's that they should be able to figure out they need all of the "cg" methods, it's kinda like that warning on ladders to not stand on the very top rung.  By the way, maybe we should discuss the state of "optional API methods" at the mid-cycle.
>>> 
>>>  * Any driver that wishes to mark their driver as supporting a
>>> non-required feature inherits this feature and fulfills the required
>>> methods.
>>> 
>>> ​Yeah... ok​, I guess.
>>> 
>>> * 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.
>>> 
>>> ​Sure, I guess my question is what's the real value in this intermediate step.  The bulk of these are things that I'd argue shouldn't be optional anyway (snapshots, transfers, manage, extend, retype and even migrate).  Snapshots in particular I find surprising to be considered as "optional“.
>> 
>> Reducing the number of classes/optional functions sounds good to me.
>> I think it’s quite valuable to discuss what are the mandatory functions
>> of a cinder driver. Before ABC nobody really cared because all drivers simply raised an run-time exception :)
> 
> If Marc is fine with this, I see no harm in us trying out John's proposal of
> using decorators in the volume driver class.
> 
> -- 
> Mike Perez


+1 sure, happy to see the code :)

Regards
Marc

> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev