charm nova-compute doesn't deregister the service on unit removal

[Patrizio Bassi]

Openstack is deployed with a openstack-base bundle via MAAS provider

juju add-unit nova-compute
<a new bare metal machine is deployed>
openstack and nova see the new compute node, and it's working
(nova service-list shows the new machine)

juju remove-unit nova-compute/X does remove the unit, the software and even releases the machine to maas, but does't deregister it self from nova service catalog

so you have to manually issue
nova service-list to get the id
nova service-remove <id>

it would be good to have this in the stop/destroy event

[Patrizio Bassi (patrizio-bassi)]

i found that even neutron-openvswitch-agent is still registered

it should be cleaned up
(now i must issue neutron agent-delete <id>)

[John A Meinel (jameinel)]

I'm pretty sure this should be considered a bug in the charm itself.

[James Page (james-page)]

I know this to be the case; its somewhat of a historic issue as very early juju versions never actually executed the stop hook, so no charm ever implemented them as they where useless with no way to test.

That said I think we could do a better job on service destruction with regards to cleanup; on a nova-compute unit this would involve:

a) destroying any active instances (or maybe migrating them?)
b) disabling/removal of nova-compute service entries in nova (via an API call)
c) removal of nova-compute related packages

this is a general pattern that could be applied across all of the charms, but a) and c) have most value on physical machines where multiple applications may be deployed directly onto the hardware.

[Wouter van Bommel (woutervb)]

When removing a unit, case should be taken for aggregate de-registration and the neutron stuff that is related to the host instance.

[Martin Kalcok (martin-kalcok)]

After the talk with the Openstack team, we determined that due to the async nature and no guaranteed order of hooks execution after the `juju remove-unit` command is executed, there will have to be a new action implemented that prepares `nova-compute` unit for departure.

In my proposal I added 4 new actions:
* disable - Disables `nova-cloud-controller` from running new VMs on the unit
* enable - Enables `nova-cloud-controller` to run new VMs on the unit
* remove-from-cloud - Stops `nova compute`, `neutron agent` and unregisters them from the nova and neutron services
* register-to-cloud - Reverts effects of the `remove-from-cloud` action

There's a new section added to README.md that explains how to perform unit removal (https://review.opendev.org/c/openstack/charm-nova-compute/+/763795/1/README.md). But basic worklof goes like this:

* Perform `disable` action on the `nova-compute` unit
* Ensure that there are no VMs running on the unit and either destroy or migrate them away.
* Perform `remove-from-cloud` action on the `nova-compute` unit
* Run `juju remove-unit` commnand

[Martin Kalcok (martin-kalcok)]

Fix committed: https://review.opendev.org/c/openstack/charm-nova-compute/+/763795