The current ccs/cluster.conf architecture allows for hierarchical "clustering" of cluster services by embedding one resource tag inside another within a service, e.g.: <service autostart="1" domain="arcims" name="arcims"> <script ref="mainwin init script"> <script ref="arcims init script"/> </script> </service> In this example, the arcims and mainwin system-level services are both part of the same cluster service, and there is an implicit dependency of arcims on mainwin - the cluster will start mainwin first, and only start arcims if starting mainwin is successful. These services are restricted to the same domain, however, and therefore in effect to the same cluster node. To define two system-level services that need to run on separate nodes normally, two domains and therefore two cluster services are required, but then there is no way to define one cluster service to be dependent on another. For instance: <service autostart="1" domain="arcsde" name="arcsde"> <script ref="arcsde init script"/> </service> <service autostart="1" domain="arcims" name="arcims"> <script ref="arcims init script"/> </service> <failoverdomains> <failoverdomain name="arcsde" ordered="1" restricted="0"> <failoverdomainnode name="MAPS1" priority="2"/> <failoverdomainnode name="MAPS2" priority="1"/> </failoverdomain> <failoverdomain name="arcims" ordered="1" restricted="0"> <failoverdomainnode name="MAPS1" priority="1"/> <failoverdomainnode name="MAPS2" priority="2"/> </failoverdomain> </failoverdomains> The arcims service needs to be started after the arcsde service, and they may run on the same node but ordinarily are desired to run on different nodes. These two requirements are mutually exclusive (afaik) in the current version. The arcims service also should be failed and restarted if the arcsde service switches nodes, which is also not easily doable without a lot of init script magic.
ccs only handles configuration propagation and synchronization; rgmanager handles dealing with dependencies.
It might be possible to do this simply by triggering off of events; e.g. when service 'arcsde' finishes starting, start service 'arcims' and when service 'arcsde' stops, stop service 'arcsde' There's a little-used callback mechanism in the distributed state subsystem in rgmanager - which could theoretically be used to generate events on service state transitions (more precisely, on the commit of the distributed state which occurs after the transition is complete). That might be a cheap way of handling this.
Moving all RHCS ver 5 bugs to RHEL 5 so we can remove RHCS v5 which never existed.