With Juju 2.8 nearly out the door, we will soon have a remove hook to mirror the install hook. This got us thinking a bit more about the “start” and “stop” hooks.
Another minor change is that the “start” hook will now be called when the unit agent starts for the first time for a particular unit after a machine restart. This primarily was to help the cold boot situation for restarting openstack clouds, but again it had us thinking more around the semantic of the start and stop hooks.
What we’d like it to mean is:
- start hook starts the workload
- stop hook stops the workload
This could then lead to additional CLI commands to stop and start the workloads for particular units. This could then lead to an additional status value for the workload to show that it had been stopped.
Where I believe there may be a wrench in the works here is around reactive charms, because as far as I know, they don’t really take into consideration what the name of the hook is in order to limit what is done.
I do believe this would work very nicely with the new operator framework, but I’m a bit hesitant around adding this type of behaviour that could potentially break reactive charms.
Perhaps the charm could say in the metadata.yaml somehow that it was a charm that supported the stop/start semantics. 