Setting libvirt-image-backend to rbd make to fail existing vms

[Giuseppe Petralia]

charm-nova-compute revision: 296
openstack version: cloud:xenial-queens

In Boostack a customer asked to move ephemeral disk to ceph.

In order to do that we set libvirt-image-backend to rbd with:

juju config nova-compute libvirt-image-backend=rbd

After the config change was applied any action that involves recreating the vm xml (stop and restart, resize, migrate) are failing for existing vms because we hit the following exception:

https://paste.ubuntu.com/p/vNCCfkTVJz/

In order to fix that we need to revert back the libvirt-image-backend to qcow2 perform the operation needed and then set it back to rbd.

We believe that at least this should be documented in the config.yaml

[Alex Kavanagh (ajkavanagh)]

TRIAGE:

So changing libvirt-image-backend for a nova host after creating instances is not a supported feature of the nova-compute charm, because (I suspect) it's not supported on nova itself. That doesn't mean that a new nova-compute (juju) application couldn't have a different libvirt-image-backend and co-exist with the other nova-compute (juju) application.

However, I agree that a documentation update would be useful to indicate that it shouldn't be done and work-arounds, and also in the config.yaml for the nova-compute charm.

It's possibly a good idea to actually make the config option and install time only config option (i.e. for it to have no effect if changed after the charm is installed). However, that might cause more problems that it solves.

[Edward Hope-Morley (hopem)]

@ajkavanagh you are correct that changing the rbd-image-backend while there are still instances in existence that are using a prior backend type is not supported by Nova (primarily because image conversion during migration is not supported). While it might be safer to make this option install-time-only I also think it might be a bit frustrating to not allow users to change their mind about backend type post-deployment. Therefore I think that adding a config option message (i.e. in config.yaml) to explain that this should not be changed while you still have running instances is a good idea. If we really wanted to make it one-shot then we could add an action to change it post-install.

[Alex Kavanagh (ajkavanagh)]

@hopem - yes, I think we are agreed. I don't really like config items you can't change later, so I was playing a bit of devil's advocate there :)

Essentially, to resolve this bug:

* In config.yaml of nova-compute charm: add note about issues around changing value and existing instances. Point to charms deployment guide.
* In charms deployment guide, add note about issues surrounding config value and workarounds.

Thanks.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/693736
Committed: https://git.openstack.org/cgit/openstack/charm-deployment-guide/commit/?id=e23edc0a81ac68881d455e5934c3344a7fa7ab68
Submitter: Zuul
Branch: master

commit e23edc0a81ac68881d455e5934c3344a7fa7ab68
Author: Peter Matulis <email address hidden>
Date: Mon Nov 11 12:48:10 2019 -0500

    Add note re consequences of changing image format

    Closes-Bug: #1826888

    Change-Id: I90e9abbae2c7fab6c88ed94ea06eaa1fa15ef60a