Solidfire: wrong AUTH info for transferred volume

[Huang Zhiteng]

When a volume is transferred from one project to another, this transferred volume cannot be attached to any instance due to wrong AUTH information. Nova-compute threw exception when trying to attach the volume:

2014-07-25 00:03:57,358.358 42302 ERROR nova.compute.manager [req-04e6cad9-0d3a-4c3c-a9b3-a9d3a0247872 6a08f3e43965436fb028eda1005ec77b b67a57cc0b9d443eac6d2ff8a494b088] [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] Failed to attach volume c946565f-d87a-48df-a6f4-baa3bb9d2300 at /dev/vdc
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] Traceback (most recent call last):
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/compute/manager.py", line 3690, in _attach_volume
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] encryption=encryption)
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1083, in attach_volume
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] disk_info)
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1042, in volume_driver_method
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] return method(connection_info, *args, **kwargs)
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/openstack/common/lockutils.py", line 246, in inner
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] return f(*args, **kwargs)
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/virt/libvirt/volume.py", line 287, in connect_volume
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] self._run_iscsiadm(iscsi_properties, ("--rescan",))
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/virt/libvirt/volume.py", line 218, in _run_iscsiadm
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] check_exit_code=check_exit_code)
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/utils.py", line 177, in execute
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] return processutils.execute(*cmd, **kwargs)
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] File "/opt/openstack/nova/2013.2.3.r7/lib/python2.7/site-packages/nova/openstack/common/processutils.py", line 178, in execute
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] cmd=' '.join(cmd))
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] ProcessExecutionError: Unexpected error while running command.
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m node -T iqn.2010-01.com.SF:ogav.uuid-c946565f-d87a-48df-a6f4-baa3bb9d2300.200982 -p ISCSITARGET:3260 --rescan
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] Exit code: 255
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] Stdout: ''
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682] Stderr: 'iscsiadm: No portal found.\n'
2014-07-25 00:03:57,358.358 42302 TRACE nova.compute.manager [instance: e02f0e44-bc32-4a5a-ba84-bf338d301682]

How to reproduce:
1) Create a volume X on Solidfire with project A;
2) Transfer volume X to project B;
3) attach volume X to any instance;

In solidfire.py:accept_transfer(), the volume metadata in the backend is changed but the AUTH (CHAP username secret) remains unchanged, which causes the mismatch of the ownership and corresponding AUTH info. Cinder volume manager will have to be changed as well to adopt cases like this (volume info must be updated to DB once driver completes accept_transfer).

[John Griffith (john-griffith)]

Fix on the way

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/110073
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=09f6fe636416ac63e1463d14d469af8f93a6ddf0
Submitter: Jenkins
Branch: master

commit 09f6fe636416ac63e1463d14d469af8f93a6ddf0
Author: John Griffith <email address hidden>
Date: Mon Jul 28 11:35:54 2014 -0600

    Get updated model info on volume transfer

    On some drivers CHAP credentials are tied to accounts
    which may be unique for each OS and/or backend Tenant.

    For example:
      Volume is created with project_id xyz
      Backend creates an account for xyz with specific CHAP

      Volume is transferred to project_id abc

    Currently we don't update the model_info, so even though
    on the backend we updated the owner and CHAP settings we
    never propogated that back up to the DB object so the volume
    can't be used by the new owner.

    This patch just adds an option to return model_update
    on the accept_transfer call to the driver and updates
    the db accordingly.

    Also adds a call in the SF driver to actually get the
    new model info to be fed back to the manager.

    Change-Id: Ie0447cdad69c4fbee99b4b6b1d3cacdfdd14137d
    Closes-Bug: #1349475

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/110200

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/110203

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/110203
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=cd7dd94bb9c97ab19b7d2636958214911f223d05
Submitter: Jenkins
Branch: stable/icehouse

commit cd7dd94bb9c97ab19b7d2636958214911f223d05
Author: John Griffith <email address hidden>
Date: Mon Jul 28 11:35:54 2014 -0600

    Get updated model info on volume transfer

    On some drivers CHAP credentials are tied to accounts
    which may be unique for each OS and/or backend Tenant.

    For example:
      Volume is created with project_id xyz
      Backend creates an account for xyz with specific CHAP

      Volume is transferred to project_id abc

    Currently we don't update the model_info, so even though
    on the backend we updated the owner and CHAP settings we
    never propogated that back up to the DB object so the volume
    can't be used by the new owner.

    This patch just adds an option to return model_update
    on the accept_transfer call to the driver and updates
    the db accordingly.

    Also adds a call in the SF driver to actually get the
    new model info to be fed back to the manager.

    Closes-Bug: #1349475

    Conflicts:
     cinder/volume/drivers/solidfire.py

    Change-Id: Ie0447cdad69c4fbee99b4b6b1d3cacdfdd14137d

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/110200
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=0058f5ac5b58b91091fbc23e847ce0a4dd54141e
Submitter: Jenkins
Branch: stable/havana

commit 0058f5ac5b58b91091fbc23e847ce0a4dd54141e
Author: John Griffith <email address hidden>
Date: Mon Jul 28 11:35:54 2014 -0600

    Get updated model info on volume transfer

    On some drivers CHAP credentials are tied to accounts
    which may be unique for each OS and/or backend Tenant.

    For example:
      Volume is created with project_id xyz
      Backend creates an account for xyz with specific CHAP

      Volume is transferred to project_id abc

    Currently we don't update the model_info, so even though
    on the backend we updated the owner and CHAP settings we
    never propogated that back up to the DB object so the volume
    can't be used by the new owner.

    This patch just adds an option to return model_update
    on the accept_transfer call to the driver and updates
    the db accordingly.

    Also adds a call in the SF driver to actually get the
    new model info to be fed back to the manager.

    Closes-Bug: #1349475

    Conflicts:
     cinder/volume/drivers/solidfire.py

    Change-Id: Ie0447cdad69c4fbee99b4b6b1d3cacdfdd14137d
    (cherry picked from commit 09f6fe636416ac63e1463d14d469af8f93a6ddf0)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/111359

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/111359
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=a1135b707d19abfd4acdfcf00ae0b28ec727b2c0
Submitter: Jenkins
Branch: stable/icehouse

commit a1135b707d19abfd4acdfcf00ae0b28ec727b2c0
Author: Zhiteng Huang <email address hidden>
Date: Sat Aug 2 01:50:47 2014 +0800

    Fix solidfire accept_transfer

    Previous fix has a mistake which makes the situation worse. This change
    fix volume['project_id'] and volume['user_id'] and adds unit test for
    accept_transfer.

    Closes-bug: # 1349475

    Change-Id: I7b2bcefa4c8d173689cc63ee5aa9e00397c7f8ca
    (cherry picked from commit 5dbdb11e8d8659a6b823c9552052b443050886ca)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/111351
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=5dbdb11e8d8659a6b823c9552052b443050886ca
Submitter: Jenkins
Branch: master

commit 5dbdb11e8d8659a6b823c9552052b443050886ca
Author: Zhiteng Huang <email address hidden>
Date: Sat Aug 2 01:50:47 2014 +0800

    Fix solidfire accept_transfer

    Previous fix has a mistake which makes the situation worse. This change
    fix volume['project_id'] and volume['user_id'] and adds unit test for
    accept_transfer.

    Closes-bug: # 1349475

    Change-Id: I7b2bcefa4c8d173689cc63ee5aa9e00397c7f8ca

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/111594

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/111594
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=95a6a109efc0ed1d7106814bec8b714a84bdfab1
Submitter: Jenkins
Branch: stable/havana

commit 95a6a109efc0ed1d7106814bec8b714a84bdfab1
Author: Zhiteng Huang <email address hidden>
Date: Sat Aug 2 01:50:47 2014 +0800

    Fix solidfire accept_transfer

    Previous fix has a mistake which makes the situation worse. This change
    fix volume['project_id'] and volume['user_id'] and adds unit test for
    accept_transfer.

    Closes-bug: # 1349475

    Conflicts:
     cinder/tests/test_solidfire.py

    Change-Id: I7b2bcefa4c8d173689cc63ee5aa9e00397c7f8ca
    (cherry picked from commit 5dbdb11e8d8659a6b823c9552052b443050886ca)