Am 08.07.2015 um 01:37 schrieb Mike Perez <[email protected]>:

> On 18:38 Jun 22, Marc Koderer wrote:
>> 
>> Am 20.06.2015 um 01:59 schrieb John Griffith <[email protected]>:
>>> * 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: [email protected]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Reply via email to