No actions to stop/start the MON process

[Peter Matulis]

I do not see any actions that actually stops/starts a Ceph monitor.

Suggested action names and descriptions, based on other bugs:

pause Pause the Ceph monitor service.
resume Resume the Ceph monitor service.

[Peter Matulis (petermatulis)]

Not sure if it's related, but for a MON cluster of 3 (ceph-mon/0 , ceph-mon/1, ceph-mon/2),

I stop a service manually:

$ juju ssh ceph-mon/0 sudo systemctl stop ceph-mon.service

and the MON cluster loses quorum and I can no longer query the cluster, as expected.

The output to `juju status` first showed ceph-mon/2 being 'blocked', and followed by units 0 and 1 also being 'blocked'.

However, when I bring back the service:

$ juju ssh ceph-mon/0 sudo systemctl start ceph-mon.service

Units 0 and 1 turn to 'active' while 2 remains 'blocked'.

I can query the cluster successfully:

$ juju ssh ceph-mon/1 sudo ceph status

[Peter Matulis (petermatulis)]

The output to `juju status` I was left with:

http://paste.ubuntu.com/p/WkxqCwtPyW/

[Chris MacNaughton (chris.macnaughton)]

What is the motivation for actually stopping the ceph monitor service? For a system shutdown, the cluster won't behave badly because the monitor went offline without specific action, and no specific action will help the quorum in the event of a wider outage.

[Peter Matulis (petermatulis)]

In general, a Juju operator should have the ability to enable/disable any service deployed by Juju. We shouldn't need to ask why. But in particular, on hyperconverged nodes, when actions *are* used for other services, those services will not come up until the inverse action is applied after boot time. However, the MON service *will* come up if it wasn't paused via an action. Meaning that the MON will come up before the other service, which may not be desirable. So, yes, all charms should come with actions that allow for the controlled shutdown and startup of services.