On Thu, Sep 24, 2015 at 3:21 PM, Price, Loren <[email protected]> wrote:
> Hi John, > > > > Okay, it sounds like we’ll be okay to implement the replication V2 spec. I > believe the failover aspect was the only API that we were seeing a problem > with. It also sounds like there might be some areas for improvement around > documentation, etc. Let me know if there’s anything I/we can do to help on > that. > > > > Thanks, > > > > Michael > > > > *From:* John Griffith [mailto:[email protected]] > *Sent:* Thursday, September 24, 2015 2:26 PM > *To:* Price, Loren > *Cc:* [email protected] > *Subject:* Re: [Openstack] [Cinder] Questions on implementing the > Replication V2 spec > > > > > > > > On Thu, Sep 24, 2015 at 11:48 AM, Price, Loren <[email protected]> > wrote: > > Hey, > > > > We’re looking into implementing the VolumeReplication_V2 > <https://github.com/openstack/cinder-specs/blob/master/specs/liberty/replication_v2.rst> > spec for our NetApp E-Series volume driver. Looking at the specification, I > can foresee a problem with implementing the new API call > “failover_replicated_volume(volume) “ > with an unmanaged replication target. I believe with a managed target we > can provide it, if I’m understanding correctly that it merely requires > updating the host id for the volume. Based on that, I have two questions: > > > > 1. Is it acceptable, in implementing this spec, to only provide this > API for managed targets (and either throw an exception or essentially make > a no-op) for an unmanaged replication target? > > 2. In general, if a storage backend is incapable of performing a > certain operation, what is the correct way to handle it? Can the driver > implement the spec at all? Should it throw a NotImplementedError? No-op? > > > > Thanks, > > > > Michael Price > > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : [email protected] > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Ooops, did I not respond to the list on that last response? Just incase > here it is again: > > > > > > 1. Is it acceptable, in implementing this spec, to only provide this > API for managed targets (and either throw an exception or essentially make > a no-op) for an unmanaged replication target? > > Yes by > > > > design it's set up such that it's left up to configuration. In other > words the idea is that we have fairly loose definitions around the API > calls themselves to allow for differing implementations. > > 2. In general, if a storage backend is incapable of performing a > certain operation, what is the correct way to handle it? Can the driver > implement the spec at all? Should it throw a NotImplementedError? No-op? > > Depends on who you ask :) IMO we need to do a better job of this, this > could be documenting in the deployment guides how to enable/disable API > calls in certain deployments so that unsupported calls are just flat out > not available. My true belief is that we shouldn't be implementing > features that you can't run with every/any backend device in the first > place, but that's my usual rant and somewhat off topic here :) > > > > Note that a lot of the logic for replication in V2 was moved into the > volume-type and the conf file precisely to address some of the issues you > mention above. The idea being that if the capabilities of the backend > don't match replication specs in the type then the command fails for > no-valid host. The one thing I don't like about this is how we relay that > info to the end user (or more accurately the fact that we don't). We just > put the volume in error state and the only info regarding why is in the > logs which the end user doesn't have. This is where something like a > better more clear policy file would help as well as providing a > capabilities call in the API. > > > > By the way, I'm glad you asked these questions here. This is part of the > reason why I was so strongly opposed to merging an implementation of the V2 > replication in Liberty. I think it's important to have more than one or > two vendors looking at this and working out details so we release something > that is stable and usable. My philosophy is that now for M we have a > foundation in the core code that will likely evolve as drivers begin > implementing the feature. > > > By the way, have you looked at this at all (or is that what you're referencing)[1]? Might be more useful than the spec at this point. [1]: https://github.com/openstack/cinder/blob/master/doc/source/devref/replication.rst
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
