[openstack-dev] [cinder] consistency groups in ceph

Victor Denisov vdenisov at mirantis.com
Mon Dec 5 23:15:55 UTC 2016


Hi Xing,

One more question. You mentioned that there is an operation: create
consistency group from a snap shot.
Does it mean that an image can be a member of several consistency groups?

Thanks,
V.

On Tue, Nov 8, 2016 at 6:21 AM, yang, xing <Xing.Yang at dell.com> wrote:
> You cannot remove a volume completely if there is still a group snapshot.  You can remove the volume from the group but you can’t delete the volume because it still has snapshot dependent on it.  So if you want to completely remove a volume that is in a group, you can delete the group snapshot first which will delete the individual snapshot.  After that you can remove the volume from the group and delete the volume.
>
> More comments inline below.
>
> Thanks,
> Xing
>
>
> ________________________________________
> From: Victor Denisov [vdenisov at mirantis.com]
> Sent: Tuesday, November 8, 2016 12:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> One more question. What is the expected behavior if you remove a
> volume completely?
> [Xing] You cannot remove the volume completely (delete volume won't succeed) if there is still a group snapshot.
>
> Should the group snapshot removed first? Should the volume snapshot be
> removed from the group snapshot?
> [Xing] Yes, you should delete the group snapshot first and that will delete the volume snapshot as well.
>
> Should we keep the snapshot even if the image doesn't exist anymore?
> [Xing] You cannot delete the image (volume) if there is still a snapshot.
>
> Thanks,
> Victor.
>
> On Tue, Nov 1, 2016 at 7:02 AM, yang, xing <Xing.Yang at dell.com> wrote:
>> Hi Victor,
>>
>> Please see my answers inline below.
>>
>> In Newton, we added support for Generic Volume Groups.  See doc below.  CGs will be migrated to Generic Volume Groups gradually.  Drivers should not implement CGs any more.  Instead, it can add CG support using Generic Volume Group interfaces.  I'm working on a dev doc to explain how to do this and will send an email to the mailing list when I'm done.  The Generic Volume Group interface is very similar to CG interface, except that the Generic Volume Group requires an additional Group Type parameter to be created.  Using Group Type, CG can be a special type of Generic Volume Group.  Please feel free to grab me on Cinder IRC if you have any questions.  My IRC handle is xyang or xyang1.
>>
>> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>>
>> Thanks,
>> Xing
>>
>>
>> ________________________________________
>> From: Victor Denisov [vdenisov at mirantis.com]
>> Sent: Monday, October 31, 2016 11:29 PM
>> To: openstack-dev at lists.openstack.org
>> Cc: Jason Dillaman
>> Subject: [openstack-dev] [cinder] consistency groups in ceph
>>
>> Hi,
>>
>> I'm working on consistency groups feature in ceph.
>> My question is about what kind of behavior does cinder expect from
>> storage backends.
>> I'm particularly interested in what happens to consistency groups
>> snapshots when I remove an image from the group:
>>
>> Let's imagine I have a consistency group called CG. I have images in
>> the consistency group:
>> Im1, Im2, Im3, Im4.
>> Let's imagine we have snapshots of this consistency group:
>>
>> CGSnap1
>> CGSnap2
>> CGSnap3
>>
>> Snapshots of individual images in a consistency group snapshot I will call
>> CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.
>>
>> Qustion 1:
>> If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
>> Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.
>>
>> Can CGSnap1 have less images than it already has: Im1, Im2, Im3.
>>
>> [Xing]  Once a snapshot is taken from a CG, it can no longer be changed.  It is a point-in-time copy.  CGSnap1 cannot be modified.
>>
>> Question 2:
>> If we remove image2 from the consistency group. Does it mean that
>> snapshots of this image should be removed from all the CGSnaps.
>>
>> Example:
>> We are removing Im2.
>> CGSnaps look like this:
>>
>> CGSnap1 - CGSnap1Im1, CGSnap1Im2, CGSnap1Im3
>> CGSnap2 - CGSnap2Im1, CGSnap2Im2, CGSnap2Im3, CGSnap3Im4
>> CGSnap3 - CGSnap3Im1, CGSnap3Im2, CGSnap3Im3, CGSnap3Im4
>>
>> What happens to snapshots: CGSnap1Im2,CGSnap2Im2, CGSnap3Im2? Do we
>> remove them, do we keep them. Is it important what we do to them at
>> all?
>>
>> [Xing] If your CG contains 4 volumes when you take the snapshot of the CG, the resulting CGSnap should be associated with 4 snapshots corresponding to the 4 volumes.  If you add more volumes to the CG or remove volumes from CG after CGSnap was taken, it should not affect CGSnap.  It will only affect CG snapshots that you take in the future.
>>
>> Thanks,
>> Victor.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list