So, a further update here. After some more discussions, it was decided that we should drop the action idea and shift to "if the operator does a config changed or charm upgrade (refresh), then they know what they are doing and so it is okay to stop the service, do the snap refresh, and then restart the service in a sealed state."
Obviously, this will happen across all the units, so the entire vault application's units will be sealed at that point, and will require the operator to unseal the vault.
So, we should definitely ensure that there is a warning in the config.yaml of the charm, and also update the charm-guide to include some commentary around vault charm upgrades.
So, a further update here. After some more discussions, it was decided that we should drop the action idea and shift to "if the operator does a config changed or charm upgrade (refresh), then they know what they are doing and so it is okay to stop the service, do the snap refresh, and then restart the service in a sealed state."
Obviously, this will happen across all the units, so the entire vault application's units will be sealed at that point, and will require the operator to unseal the vault.
So, we should definitely ensure that there is a warning in the config.yaml of the charm, and also update the charm-guide to include some commentary around vault charm upgrades.