yahoo-eng-team team mailing list archive

[OpenStack Infra <1625660@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/373390
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ee2c0a00db9d6006fb7c3a07ee252d4ca4d73eff
Submitter: Jenkins
Branch:    master

commit ee2c0a00db9d6006fb7c3a07ee252d4ca4d73eff
Author: Sylvain Bauza <sbauza@xxxxxxxxxx>
Date:   Tue Sep 20 16:50:16 2016 +0200

    Revert "Set 'serial' to new volume ID in swap volumes"
    
    The below commit introduced a regression by updating the wrong value to
    the attachment field when calling the volume-update swap operation where
    the value is now the previous volume ID instead of the current volume
    ID. It litterally makes it now imposible to detech the volume from the
    instance once it has been swapped (even after the first swap).
    
    Given the original issue can be worked around by detaching and then
    attaching the volume before swapping back to the original volume, and
    because the original bug only impacts an admin API while here it impacts
    a user API, it's preferrable to directly revert the regression and then
    work on the next cycle about the root problem rather than leaving the
    change and try to fix something which is hard to troubleshoot, also
    given the lack of functional tests around the volume operations.
    
    This reverts commit be553fb15591c6fc212ef3a07c1dd1cbc43d6866.
    
    Change-Id: Ibad1afa5860d611e0e0ea0ba5e7dc98ae8f07190
    Closes-Bug: #1625660


** Changed in: nova
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1625660

Title:
  Volume detach is broken when using volume-update first

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  https://bugs.launchpad.net/nova/+bug/1490236 was focusing on
  correcting the volume-update API so that it was idempotent.
  Unfortunately, the merged solution is introducing a huge regression by
  incorrectly providing the old volume ID as the new attachment
  information.

  https://github.com/openstack/nova/commit/be553fb15591c6fc212ef3a07c1dd1cbc43d6866

  
  Consequently, it's now impossible for an end-user to detach a volume if some operator updated the BDM to point to a different volume.

  Evidence here: http://paste.openstack.org/show/582248/

  What's unfortunate is that the original bug is about to be worked
  around by just detaching/attaching the volume to the instance before
  swapping back...

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1625660/+subscriptions