Cloned volume is associated with wrong SolidFire account

[Mathieu Gagné]

When cloning a volume owned by a tenant (A) to an other tenant (B), the cloned volume is associated with the wrong SolidFire account (A).

Steps to reproduce the problem:
1. Have volume 1 owned by tenant A
2. Have a keystone user member of tenant A and tenant B with admin role
3. Clone volume 1 to tenant B, therefore creating volume 2.

Actual results:
* Cinder associates the (cloned) volume 2 to tenant B.
* SolidFire driver does not create any SolidFire account for tenant B.
* If tenant B does NOT already have a SolidFire account on SolidFire cluster
    * The cloning process fails at create_export because it cannot find the corresponding SolidFire account (B).
* If tenant B DOES already have a SolidFire account on SolidFire cluster
    * SolidFire driver associates volume 2 to SolidFire account of tenant A.
    * Cloned volume CANNOT be cloned twice, it fails because SolidFire driver cannot find the volume in the SolidFire account of tenant B.

Expected results:
* Cinder associates (cloned) volume 2 to tenant B.
* SolidFire driver creates a SolidFire account for tenant B. (if it does not exist)
* SolidFire driver associates volume 2 to SolidFire account of tenant B.
* SolidFire driver is able to clone twice (or more) a cloned volume.

[John Griffith (john-griffith)]

This isn't intended to work. We're in the process of introducing tenant-transfers of volumes that will address this but in the current driver this is not expected to work. We've looked at doing a "super-tenant" sort of along the lines of what you've done but instead we're working on adding API calls specifically to deal with this and include some key management as well as some cleanup routines for volumes that were released, but never claimed.

[John Griffith (john-griffith)]

BTW, the issue of a project-id/account other than "tenant A" being assigned is a bug, the intended behavior is that everything is built off of the source-volume reference, including project etc.

I'll look into that piece of things right away and get a fix in.

[OpenStack Infra (hudson-openstack)]

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

[Mathieu Gagné (mgagne)]

Regarding #2, this won't work out for us. Our system is based on this "feature" and fixing it will break it.

I proposed a patch fixing the problem I reported.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/30323
Committed: http://github.com/openstack/cinder/commit/af023fe0cce3b8ef2b90ec37f1bc49feb17eac83
Submitter: Jenkins
Branch: master

commit af023fe0cce3b8ef2b90ec37f1bc49feb17eac83
Author: Mathieu Gagné <email address hidden>
Date: Thu May 23 15:26:44 2013 -0400

    Fix ownership transfer when cloning with SolidFire

    When cloning a volume with SolidFire driver, the owner of
    the cloned volume is not set correctly in SolidFire when there is
    a transfer of ownership.

    This results in inconsistent states where the cloned volume
    is owned by the new tenant in Cinder but SolidFire thinks it is still
    owned by the original volume's tenant.

    This patch adds the newAccountID parameter to all CloneVolume calls.

    If the cloned volume is owned by the same tenant, newAccountID will
    be set to the same value as the original SolidFire volume. There
    will be no change of ownership done by the cloning process in SolidFire.

    If the cloned volume should be owned by a different tenant, newAccountID
    will be set to the appropriate SolidFire account corresponding
    to the new tenant. If the SolidFire account does not exist already,
    it will be created.

    Fixes: bug #1183521
    Change-Id: I622ca2962478298e3e0c5a26866e39919805075f

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/30547

[John Griffith (john-griffith)]

It seems this is a more common use case than I had initially thought, there's been another customer asking about it as well as one asking if the use case works. Based on that I think I was wrong in my initial categorization and I think this should be medium (of course for folks that want to use the feature it's a High)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/30547
Committed: http://github.com/openstack/cinder/commit/c56d031bc80077658faf481a3e7693991e83a575
Submitter: Jenkins
Branch: stable/grizzly

commit c56d031bc80077658faf481a3e7693991e83a575
Author: Mathieu Gagné <email address hidden>
Date: Thu May 23 15:26:44 2013 -0400

    Fix ownership transfer when cloning with SolidFire

    When cloning a volume with SolidFire driver, the owner of
    the cloned volume is not set correctly in SolidFire when there is
    a transfer of ownership.

    This results in inconsistent states where the cloned volume
    is owned by the new tenant in Cinder but SolidFire thinks it is still
    owned by the original volume's tenant.

    This patch adds the newAccountID parameter to all CloneVolume calls.

    If the cloned volume is owned by the same tenant, newAccountID will
    be set to the same value as the original SolidFire volume. There
    will be no change of ownership done by the cloning process in SolidFire.

    If the cloned volume should be owned by a different tenant, newAccountID
    will be set to the appropriate SolidFire account corresponding
    to the new tenant. If the SolidFire account does not exist already,
    it will be created.

    Fixes: bug #1183521
    Change-Id: I622ca2962478298e3e0c5a26866e39919805075f
    (cherry picked from commit af023fe0cce3b8ef2b90ec37f1bc49feb17eac83)