Open Stack

Just want to clarify that when the driver gets a list of volume objects as an input parameter in create_group_from_src, volume.name will be in the format of volume-<uuid>.  If you look at the database, however, the display_name field is None.

Xing

________________________________________
From: yang, xing [Xing.Yang at dell.com]
Sent: Tuesday, December 6, 2016 11:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

No, the new cloned image (volume) will get this name (volume-uuid) automatically.  The driver does not need to specify a name.

Xing

________________________________________
From: Victor Denisov [vdenisov at mirantis.com]
Sent: Tuesday, December 6, 2016 10:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

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.Yang at 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 [vdenisov at 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.Yang at dell.com> wrote:
>> Hi Victor,
>>
>> Yes, you are right.
>>
>> Thanks,
>> Xing
>>
>> ________________________________________
>> From: Victor Denisov [vdenisov at 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 <vdenisov at 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 <vdenisov at 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.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
>>
>> __________________________________________________________________________
>> 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

__________________________________________________________________________
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