Create from snapshot will not honor volume-type if backend would need to change

[Andrew Kerr]

Environment: Multi-backend using volume-types to dictate which backend a volume gets created on.

Issue: If you create a snapshot of a volume (volume-type Red) and then attempt to create a new volume from that snapshot of volume-type Blue, the new volume-type is ignored and the new volume is created on the Red backend.

cinder create --snapshot-id a3f54851-2bf2-4acf-a74e-152e4db13c0f --display_name jonclisnapcreate2 --volume-type Blue 4
+---------------------+--------------------------------------+
| Property | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| created_at | 2014-02-03T21:39:41.284937 |
| display_description | None |
| display_name | jonclisnapcreate2 |
| id | 093ae42f-96a7-4645-b203-0cd5e539d007 |
| metadata | {} |
| size | 4 |
| snapshot_id | a3f54851-2bf2-4acf-a74e-152e4db13c0f |
| source_volid | None |
| status | creating |
| volume_type | Red |
+---------------------+--------------------------------------+

As an end-user my expectation would be that the new volume would be created on the appropriate backend using the requested volume-type.

[John Griffith (john-griffith)]

yes, the current behavior of create-from-snap and create-from-volume only works when going to and from the same backend. Sadly we are not clear/explicit on this.

First step to cleaning this up is making sure the requested dest type is serviceable from the same backend as the source. Check that right away and fail if not.

[Avishay Traeger (avishay-il)]

Agree with John.
We have at least two options for fixing this:

1) Call the scheduler's host_passes_filters function to ensure that the host can handle the new volume's type. If not, return an error. The user can then create the volume with the original volume's type, and then call retype if the deployment supports it. This is the easiest solution to code, but intrusive on the user and breaks the storage virtualization illusion (user is now aware of hosts with different capabilities).

2) We implement a new code path to handle these cases. The scheduler will check if the current host can handle the new volume's type, and if so, allow the create_volume request to continue as usual. If the host cannot handle it, we have two options: (a) create a volume on the new host, attach the original and the new (this requires attaching snapshots for the snap->vol case) and run 'dd', (b) create the new volume on the first volume's host and call retype. In terms of efficiency, there are backends where option 'a' will be more efficient, and others where option 'b' is more efficient.

Thoughts? Additional options?

[Andrew Kerr (andrew-kerr)]

I like option 2 in comment 2 best so far (no strong feelings at the moment on a vs b). My concern with simply failing if the backend doesn't support the snapshot's original type is that from a user persecutive, I have no easy way to know which snapshots are valid. Horizon simply offers up all available snapshots without any filtering based on backend appropriateness. It also seems onerous on the user to force them into a 2 step process of create the snapshot with the original settings and then migrate and change type when that is something that *could* be automated. I understand it would require a lot of work from a programmers perspective, but we must also consider the user perspective.

[John Griffith (john-griffith)]

One other option and maybe the better so far.... remove the ability to specify types on clone and create-from-snap altogether. This is getting redundant between migrate, replicate and retype.

The use case is what really matters here, so I think we could just always use the parent volume type for clone and create-from-snap, that way we're always getting the efficient process and it removes all of this confusion.

Then if a user wants to assign a different type to the child volume, they use the retype and have more control over whether a potentially slow and painful migration is done.

I'm a bit uncomfortable with having all of this overlap in the various API commands. It creates quite a bit of confusion and the docs for these types of features looks like code with "if "you did this"; elif "this"; elif "that"".... It's now way to create an API IMO.

[Ben Swartzlander (bswartz)]

I agree with John that specifying a volume type when creating volumes from snapshots or other volumes isn't needed because you can always re-type afterwards. Since the existing code seems to have this limitation we could be better off just clearly documenting the existing behavior and fixing Horizon to grey out the volume type dropdown when a source volume or source shapshot is selected.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/72488

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/72488
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=68228eb7f41f419eec2427a5e1a14f6612a705ff
Submitter: Jenkins
Branch: master

commit 68228eb7f41f419eec2427a5e1a14f6612a705ff
Author: john-griffith <email address hidden>
Date: Mon Feb 10 14:42:43 2014 -0700

    Check type argument on create from source and snap

    Currently the create from snap and create from source
    options will set the volume-type when specified in the
    create call.

    This is actually wrong, because clone and create from snap
    MUST be performed on the same backend as the parent volume. The
    result is that if the specified type doesn't match the specs for
    it's parent, and actually needs to be on a different backend
    the new volume will "appear" to have the correct type, but it's
    actually invalid.

    The --volume-type argument should be rejected when --source-volid
    or --snapshot-id are used, and the parent type-id just picked up
    and used. Then the user can retype if desired.

    Auto failing this strictly causes backward compatability issues though
    so we'll just check for a mismatch and raise an exception in that case.
    This way if the user knows what they're doing and they're explicit
    in the command we still allow it and things are fine.

    Change-Id: Ia822cfe48a948045ccea6533bcf92e68ed97ef37
    Closes-Bug: 1276787