Subject: Re: [openstack-dev] [cinder] generic volume groups
and consistency groups


Just want give an update on the work to migrate consistency groups to generic
volume groups. The migration script and code in CG APIs to handle migrating
CGs to groups are all merged. This has an impact on drivers already supporting
consistency groups.

A group type named default_cgsnapshot_type will be created by the db migration
script once you’ve upgraded to the latest code. The following command needs to
be manually run to migrate data and copy data from consistencygroups to groups
and from cgsnapshots to group_snapshots tables. Migrated consistencygroups and
cgsnapshots will be removed from the database:

cinder-manage db online_data_migrations
--max_count <max>

One noticeable change is that the Create CG API will create an entry in the
groups table, not in the consistencygroups table. The default_cgsnapshot_type
is reserved for migrating CGs. Groups with default_cgsnapshot_type can only be
operated by using the CG APIs. After migration is complete and all CG tables
are removed, we will allow default_cgsnapshot_type to be used by group APIs.

For driver maintainers who want to know more on how to add CG capability to
generic volume groups, please read the following doc:

Please remember the deadline for drivers already supporting CG to submit a
patch to add CG capability to groups is Pike-1. There’s an example on how to
implement that in the above doc.


From: yang, xing
Sent: Thursday, November 3, 2016 11:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder] generic volume groups and consistency groups

Hi everyone,

Generic volume groups support was added in Cinder in Newton. We are planning
to migrate consistency groups to generic volume groups. I have submitted a dev
doc patch to explain how to add consistency groups support in generic volume
groups in a driver. Let me know if you have any questions or provide comments
on the patch.

As discussed at the summit in Barcelona, drivers already supporting CG should
add CG support in generic volume groups by Pike-1. Drivers planning to
introduce CG support should implement the driver interfaces for generic volume
groups instead. Drivers wanting generic volume groups but not CG do not need
code changes because the default implementation should work for every driver.
Please see details in the above patch.


IRC: xyang or xyang1

From: yang, xing [[email protected]]
Sent: Tuesday, November 1, 2016 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

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.


From: Victor Denisov [[email protected]]
Sent: Monday, October 31, 2016 11:29 PM
To: [email protected]
Cc: Jason Dillaman
Subject: [openstack-dev] [cinder] consistency groups in ceph


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:


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.

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

[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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe

Programming list archiving by: Enterprise Git Hosting