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 https://review.opendev.org/#/c/584849/

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 https://bugs.launchpad.net/nova/+bug/1852106

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 https://review.opendev.org/#/c/608696/