← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1913575] [NEW] Use auth_username when probing encrypted rbd volumes while extending them

 

Public bug reported:

Description
===========

I0c3f14100a18107f7e416293f3d4fcc641ce5e55 introduced new logic around
resizing encrypted LUKSv1 volumes that probed the volume using qemu-img
to determine the LUKSv1 header size and to take this into account during
the resize. The use of qemu-img however assumes access to the admin rbd
keyring as a username isn't provided. This isn't always available in all
environment so the options `id:$username` need to be appended on the rbd
URI provided to qemu-img.

Steps to reproduce
==================

Attempt to resize an encrypted LUKSv1 volume on a compute without access
to the admin keyring.

Expected result
===============

The URI provided to qemu-img includes the username (and thus local
keyring) to use.

Actual result
=============

qemu-img fails as it can't find the default admin keyring.

Environment
===========
1. Exact version of OpenStack you are running. See the following
  list for all releases: http://docs.openstack.org/releases/

  master

2. Which hypervisor did you use?
   (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
   What's the version of that?

   libvirt + KVM

2. Which storage type did you use?
   (For example: Ceph, LVM, GPFS, ...)
   What's the version of that?

   c-vol ceph

3. Which networking type did you use?
   (For example: nova-network, Neutron with OpenVSwitch, ...)


   N/A

Logs & Configs
==============

3e004ad2953a4aa7a2f9022be3ffc7cd - default default] [instance: 8d640d15-30dd-4e72-a9ba-d9f7cf11b1ec] Unknown error when attempting to find the payload_offset for LUKSv1 encrypted disk rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39.: nova.exception.InvalidDiskInfo: Disk info file is invalid: qemu-img failed to execute on rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39 : Unexpected error while running command.
Command: /usr/libexec/platform-python -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39 --output=json --force-share
Exit code: 1
Stdout: ''
Stdout: ''
Stderr: "qemu-img: Could not open 'rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39': error connecting: Permission denied\n"

** Affects: nova
     Importance: Undecided
     Assignee: Lee Yarwood (lyarwood)
         Status: New


** Tags: ceph volumes

-- 
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/1913575

Title:
  Use auth_username when probing encrypted rbd volumes while extending
  them

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===========

  I0c3f14100a18107f7e416293f3d4fcc641ce5e55 introduced new logic around
  resizing encrypted LUKSv1 volumes that probed the volume using qemu-
  img to determine the LUKSv1 header size and to take this into account
  during the resize. The use of qemu-img however assumes access to the
  admin rbd keyring as a username isn't provided. This isn't always
  available in all environment so the options `id:$username` need to be
  appended on the rbd URI provided to qemu-img.

  Steps to reproduce
  ==================

  Attempt to resize an encrypted LUKSv1 volume on a compute without
  access to the admin keyring.

  Expected result
  ===============

  The URI provided to qemu-img includes the username (and thus local
  keyring) to use.

  Actual result
  =============

  qemu-img fails as it can't find the default admin keyring.

  Environment
  ===========
  1. Exact version of OpenStack you are running. See the following
    list for all releases: http://docs.openstack.org/releases/

    master

  2. Which hypervisor did you use?
     (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
     What's the version of that?

     libvirt + KVM

  2. Which storage type did you use?
     (For example: Ceph, LVM, GPFS, ...)
     What's the version of that?

     c-vol ceph

  3. Which networking type did you use?
     (For example: nova-network, Neutron with OpenVSwitch, ...)

  
     N/A

  Logs & Configs
  ==============

  3e004ad2953a4aa7a2f9022be3ffc7cd - default default] [instance: 8d640d15-30dd-4e72-a9ba-d9f7cf11b1ec] Unknown error when attempting to find the payload_offset for LUKSv1 encrypted disk rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39.: nova.exception.InvalidDiskInfo: Disk info file is invalid: qemu-img failed to execute on rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39 : Unexpected error while running command.
  Command: /usr/libexec/platform-python -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39 --output=json --force-share
  Exit code: 1
  Stdout: ''
  Stdout: ''
  Stderr: "qemu-img: Could not open 'rbd:volumes/volume-d721825d-038a-42f6-8127-aaec171e5c39': error connecting: Permission denied\n"

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


Follow ups