[ptg][nova][cinder] x-p meeting minutes

Lee Yarwood lyarwood at redhat.com
Tue Nov 12 15:09:08 UTC 2019

On 12-11-19 15:07:05, Sylvain Bauza wrote:
> Excerpts taken from https://etherpad.openstack.org/p/shanghai-ptg-cinder
> We discussed two items :
> 1/ Improving replication
>    - When a failover happens volumes are no longer usable in Nova.
>    - Nova should start re-attaching volumes after a failover?
>    - Why can't we detach and attach the volume?  Data that is in flight
>    would be lost.
>    - Question about boot from volume.  In that case the instance is dead
>    anyway because access to the volume has been lost.
>    - Could go through the shutdown, detach, attach, reboot path.
>    - Problem is that detach is going to fail.  Need to force it or handle
>    the failure.
>    - We aren't sure that Nova will allow a detach of a boot volume.
>    - Also don't currently have a force detach API.
>    - AGREE:  Need to figure out how to pass the force to os-brick to detach
>    volume and when rebooting a volume.

I started looking at this a while ago in the review below:

libvirt: Wire up a force disconnect_volume flag

I'll restore and see if it's still valid for the above. 
> 2/ Nova bug for images created from encrypted volumes
>    - Nova is not creating a new key for encrypted images but the deletion
>    policy metadata can allow a key to be deleted wehn it is still in use by
>    other images or even volumes
>    - Nova needs to clone the keys when doing create image.
>    - The nova team thinks that we have found a bug that needs to be fixed.
>    We just need to open a bug.
>    - ACTION  Cinder to open a bug against Nova. (can you also ping lyarwood
>    when it's open?)

This has been created below:

Possible data loss from createImage action

As discussed in the bug the actual use case of booting an instance from
an encrypted image that itself was created from an encrypted volume has
never worked. I'm also confused by the use of cinder_ specific image
properties here but this may be because this use case was never intended
to be supported?

Anyway, I've ended up looking at the ephemeral encryption support in
Nova's Libvirt driver for most of the day and honestly it needs to be
deprecated and removed as it's never going to be able to handle anything
like this. The current implementation using a single per instance key
for all disks when use cases like this and the encrypted image spec
below require per disk keys:

Spec for the Nova part of Image Encryption

Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191112/0d8cd3ce/attachment.sig>

More information about the openstack-discuss mailing list