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.griffi...@gmail.com<mailto:john.griffi...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Friday, June 19, 2015 at 7:59 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
