yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #85059
[Bug 1913575] Re: Use auth_username when probing encrypted rbd volumes while extending them
The patch has been merged to master and backports has been proposed to stable/victoria and stable ussuri
https://review.opendev.org/q/Ia6d6dcdd7042f2aef6b3abeb5cd0f7525678a3b7
** Also affects: nova/ussuri
Importance: Undecided
Status: New
** Also affects: nova/victoria
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Fix Released
** Changed in: nova
Importance: Undecided => Medium
** Changed in: nova/victoria
Status: New => In Progress
** Changed in: nova/ussuri
Status: New => In Progress
** Changed in: nova/ussuri
Assignee: (unassigned) => Lee Yarwood (lyarwood)
** Changed in: nova/victoria
Assignee: (unassigned) => Lee Yarwood (lyarwood)
--
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):
Fix Released
Status in OpenStack Compute (nova) ussuri series:
In Progress
Status in OpenStack Compute (nova) victoria series:
In Progress
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
References