Does it mean that ceph as a backend for this feature is supposed to provide an API which allows to specify the name of each cloned image?
V. On Tue, Dec 6, 2016 at 7:17 PM, yang, xing <xing.y...@dell.com> wrote: > The new image name should be volume-uuid if you don’t change > volume_name_template in cinder.conf. The display_name field will be None for > the new volume. > > Xing > > ________________________________________ > From: Victor Denisov [vdeni...@mirantis.com] > Sent: Tuesday, December 6, 2016 7:23 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Jason Dillaman > Subject: Re: [openstack-dev] [cinder] consistency groups in ceph > > How are the names chosen for those new cloned images? > > On Tue, Dec 6, 2016 at 10:04 AM, yang, xing <xing.y...@dell.com> wrote: >> Hi Victor, >> >> Yes, you are right. >> >> Thanks, >> Xing >> >> ________________________________________ >> From: Victor Denisov [vdeni...@mirantis.com] >> Sent: Monday, December 5, 2016 7:13 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Cc: Jason Dillaman >> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph >> >> I just realized that probably we create images from individual >> snapshots of that consistency group and add those images to the new >> consistency group. >> Am I correct? >> >> On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov <vdeni...@mirantis.com> wrote: >>> Or probably when we clone a consistency group from a snapshot we >>> should clone all the images in this consistency group? >>> >>> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov <vdeni...@mirantis.com> >>> wrote: >>>> 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.y...@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 [vdeni...@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.y...@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 [vdeni...@mirantis.com] >>>>>> Sent: Monday, October 31, 2016 11:29 PM >>>>>> To: openstack-dev@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-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 >>>>> >>>>> __________________________________________________________________________ >>>>> 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 >> >> __________________________________________________________________________ >> 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 > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
