yahoo-eng-team team mailing list archive

[OpenStack Infra <1746609@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/539739
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=cafe3d066ef7021c18961d4b239a10f61db23f2d
Submitter: Zuul
Branch:    master

commit cafe3d066ef7021c18961d4b239a10f61db23f2d
Author: Matt Riedemann <mriedem.os@xxxxxxxxx>
Date:   Wed Jan 31 19:06:46 2018 -0500

    libvirt: fix native luks encryption failure to find volume_id
    
    Not all volume types put a 'volume_id' entry in the
    connection_info['data'] dict. This change uses a new
    utility method to look up the volume_id in the connection_info
    data dict and if not found there, uses the 'serial' value
    from the connection_info, which we know at least gets set
    when the DriverVolumeBlockDevice code attaches the volume.
    
    This also has to update pre_live_migration since the connection_info
    dict doesn't have a 'volume_id' key in it. It's unclear what
    this code was expecting, or if it ever really worked, but since
    an attached volume represented by a BlockDeviceMapping here has
    a volume_id attribute, we can just use that. As that code path
    was never tested, this updates related unit tests and refactors
    the tests to actually use the type of DriverVolumeBlockDevice
    objects that the ComputeManager would be sending down to the
    driver pre_live_migration method. The hard-to-read squashed
    dicts in the tests are also re-formatted so a human can actually
    read them.
    
    Change-Id: Ie02d298cd92d5b5ebcbbcd2b0e8be01f197bfafb
    Closes-Bug: #1746609


** 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/1746609

Title:
  test_boot_server_from_encrypted_volume_luks cannot detach an encrypted
  StorPool-backed volume

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Hi,

  First of all, thanks a lot for working on Nova!

  The StorPool third-party Cinder CI has been failing on every test run
  today with the same problem: the
  test_boot_server_from_encrypted_volume_luks Tempest test fails when
  trying to detach a volume with an exception in the nova-compute
  service log: "Failed to detach volume 645fd643-89fc-4b3d-
  9ea5-59c764fc39a2 from /dev/vdb: AttributeError: 'NoneType' object has
  no attribute 'format_dom'"

  An example stack trace may be seen at:
  - nova-compute log: http://logs.ci-openstack.storpool.com/18/539318/1/check/dsvm-tempest-storpool/c3daf58/logs/screen-n-cpu.txt.gz#_Jan_31_18_07_27_971552
  - console log (with the list of tests run): http://logs.ci-openstack.storpool.com/18/539318/1/check/dsvm-tempest-storpool/c3daf58/console.html

  Actually, start from http://logs.ci-openstack.storpool.com/ - any of
  the recent five or six failures can be traced back to this problem.

  Of course, it is completely possible that the (recently merged)
  StorPool Nova volume attachment driver or the (also recently merged)
  StorPool os-brick connector is at fault; if there are any
  configuration fields or method parameters that we should be
  preserving, passing through, or handling in some other way, please let
  us know and we will modify our drivers.  Also, our CI system is
  available for testing any suggested patches or workarounds.

  Thanks in advance for looking at this, and thanks for your work on
  Nova and OpenStack in general!

  Best regards,
  Peter

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