[ClusterLabs] New cluster.target to control cluster services

[Ken Gaillot]

On Mon, 2018-10-22 at 18:31 +0200, Michal Koutný wrote:
> Hello,
> I'd like to collect some feedback regarding $SUBJECT.
> 
> The current state of the main cluster services and their dependencies
> condenses into the following administrative commands:
> 
> Enable cluster services:
> systemctl enable \
>   pacemaker [sbd] [dlm]
> 
> Starting cluster:
> systemctl start pacemaker
> 
> Stopping cluster (all cluster services):
> systemctl stop corosync
> 
> It's not a great drawback but the asymmetric control is rather
> counter-intuitive and IMO it unnecessarily leaks the internal
> dependencies to the administrator.
> 
> I was thus thinking about the change below (I included only
> requirement
> dependencies, not orderings):
> 
>  # pacemaker.service
>  [Unit]
>  Requires=corosync.service
> +PartOf=cluster.target
> 
>  [Install]
> -WantedBy=multi-user.target
> 
> 
> # corosync.service
>  [Unit]
> +PartOf=cluster.target
>  [Install]
>  WantedBy=multi-user.target
> 
> 
> # sbd.service
>  [Unit]
> -PartOf=corosync.service
> +PartOf=cluster.target
>  RefuseManualStop=true
>  RefuseManualStart=true
>  [Install]
>  RequiredBy=corosync.service
>  RequiredBy=pacemaker.service
>  RequiredBy=dlm.service
> 
> 
> # dlm.service
>  [Unit]
>  Requires=corosync.service
>  [Install]
> -WantedBy=multi-user.target
> +WantedBy=cluster.target
> 
> 
> # cluster.target
> +[Unit]
> +Wants=pacemaker.service
> +[Install]
> +WantedBy=multi-user.target
> 
> The resulting control interface would be then more homogenous:
> 
> Enable cluster service:
> systemctl enable \
>   cluster.target [sbd] [dlm]
> 
> Starting cluster:
> systemctl start cluster.target
> 
> Stopping cluster:
> systemctl stop cluster.target
> 
> 
> I'm aware that there are crms/pcs commands providing the similar
> common
> control interface.
> 
> Do you have any use cases that would benefit from the cluster.target?
> What drawbacks do you see if the common cluster.target was used?
> 
> Thanks,
> Michal

It makes sense to me. Of course crm/pcs would need changes to work with
it, and it might be better to use a more specific name than "cluster"
(pacemaker-cluster? clusterlabs-ha? high-availability?).

The only drawback I see is that it's theoretically possible to deploy a
different membership layer than corosync (in the past others were
supported, and that may happen again in the future), and possible to
run corosync without pacemaker (typically for use by some custom app
with its own HA). It would be difficult to accommodate all of that, but
then again, it might not be important to do so.
-- 
Ken Gaillot <kgaillot at redhat.com>