Funny you should mention needing all of the CG methods... A VD group (ConsistencyGroupVD) was added to contain the 4 CG methods from Juno. Then more CG methods were added to VolumeDriver in Kilo, but they weren’t added to ConsistencyGroupVD. But you *can’t* add them to ConsistencyGroupVD until every driver that advertises ConsistencyGroupVD has implemented them, lest ConsistencyGroupVD imply something false. You could add them to ‘ConsistencyGroupVD_v2’, but that’s ugly. This whole VD thing seems just a little too neat, since it doesn’t lend itself to evolution of features over time. I’ve wondered if a little runtime introspection wouldn’t be a cleaner solution. -- Clinton Knight From: John Griffith <john.griffith8 at gmail.com<mailto:john.griffith8 at gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>> Date: Friday, June 19, 2015 at 7:59 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>> Subject: Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150620/119eea43/attachment.html>