Re: [ClusterLabs] New cluster.target to control cluster services

2018-10-22 Thread 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 
___
Users mailing list: Users@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org


[ClusterLabs] New cluster.target to control cluster services

2018-10-22 Thread Michal Koutný
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



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org