Open Stack

Hi,

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>
--ignore_state

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:

https://github.com/openstack/cinder/blob/master/doc/source/devref/groups.rst

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.

Thanks,
Xing


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

https://review.openstack.org/#/c/393570/

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.

Thanks,
Xing

IRC: xyang or xyang1


________________________________________
From: yang, xing [Xing.Yang at dell.com]
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.

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