Open Stack

On Mon, Jul 28, 2014 at 6:11 PM, Scott Devoid <devoid at anl.gov> wrote:

> For those of you looking for more details, here are the specs for each
> feature:
>
> 1. Replication - https://review.openstack.org/#/c/98308/
> 2. Consistency Groups - https://review.openstack.org/#/c/96665
>
> ​Yes, thanks very much for linking those Scott.  I'm not convinced that
those specs are the right way to start which is part of what I was getting
at with how "deep" to go in the Cinder API versus how much to leave up to
the Admins.
​

> Replication:
> - Looks like this is specifically for replication between two
> cinder-volume servers with the same storage driver. Which is ok for me.
> - I am concerned with the driver API around promoting replicas (e.g. only
> calling a function on the secondary) since you are probably in a network
> partition when this is called.
>

​Good point, I think the idea here was for the specific use case of
replicating across back-ends that are in the same OpenStack Cluster or
maybe DC.  In other words providing the ability to recover from a device
failure by switching over to the secondary that's included in the same
OpenStack cluster/region.

The more interesting case that seems to be coming up however is geo-rep to
perhaps a secondary OpenStack deployment, unless maybe I'm misinterpreting
some of this?
​

>
> Consistency Groups:
>

​I'll try and step through these tomorrow.  These are things that we talked
about in Atlanta, some things we had answers/solutions for, some we did
not.  Regardless these are excellent and very applicable points, thanks for
raising them here.
​

> - It looks like this proposal layers two concepts in consistency group
> creation:
>     * Marking what volume-types may be within the same consistency group.
> (Operator issue I argue.)
>     * Declaring a new consistency group with volumes in it. (User issue).
> - Can you create a consistency group with volumes from separate regions?
> - Can you create a consistency group with volumes from separate store
> backends? What about different drivers?
> - The current proposal will allow multiple volumes to be snapshotted at
> around the same time and make use of QEMU quiesce functions to ensure that
> the filesystems are in a good state when the snapshot has been made. Does a
> separate consistency group snapshot function provide any stronger
> consistency guarantees than simply calling snapshot on each volume in a for
> loop? My impression based on this implementation is no.
> - Then do we need a separate API, as indicated in the "alternatives"
> section? This essentially becomes a kind of constraint on deleting volumes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140728/d1d763d5/attachment.html>