Open Stack

On Thu, Sep 24, 2015 at 3:21 PM, Price, Loren <Michael.Price at netapp.com>
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:john.griffith at solidfire.com]
> *Sent:* Thursday, September 24, 2015 2:26 PM
> *To:* Price, Loren
> *Cc:* openstack at lists.openstack.org
> *Subject:* Re: [Openstack] [Cinder] Questions on implementing the
> Replication V2 spec
>
>
>
>
>
>
>
> On Thu, Sep 24, 2015 at 11:48 AM, Price, Loren <Michael.Price at netapp.com>
> 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     : openstack at lists.openstack.org
> 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
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150925/ffa0db9b/attachment.html>