Am 20.06.2015 um 02:34 schrieb Knight, Clinton <clinton.kni...@netapp.com>:
> 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. I agree that this is an open issue with ABC. Changing an interface only works if all drivers adapt their interface. IMHO a runtime exception should be only used as interim solution to get all drivers ported. If the driver interfaces changes quite often we need to use versions. Regards Marc > > -- > Clinton Knight > > From: John Griffith <john.griffi...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <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> > 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 __________________________________________________________________________ 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
