[Cluster-devel] skipping unused services, cman_tool join -A

Steven Dake sdake at redhat.com
Thu Jan 28 01:04:24 UTC 2010


On Wed, 2010-01-27 at 15:38 -0600, David Teigland wrote:
> On Wed, Jan 27, 2010 at 01:51:38PM -0700, Steven Dake wrote:
> > On Wed, 2010-01-27 at 14:49 -0600, David Teigland wrote:
> > > On Fri, Sep 25, 2009 at 02:27:52PM -0500, David Teigland wrote:
> > > > To avoid loading+running services that you don't use (e.g. to avoid bugs
> > > > crashing the system from a service you're not using)
> > > > 
> > > > add to cluster.conf
> > > > 
> > > > <service name="corosync_cman" ver="0"/>
> > > > <service name="openais_ckpt" ver="0"/>
> > > > 
> > > > run cman_tool join -A
> > > > 
> > > > (or set CMAN_JOIN_OPTS env var)
> > > 
> > > Currently cman_tool loads the list of services defined by
> > > "openaisserviceenablestable", which is clm, evt, ckpt, msg, lck, tmr.
> > > 
> > > I suggest that by default cman_tool only load the services that we use,
> > > namely ckpt (and cman of course).  If someone wants to use another of the
> > > services, they can use cluster.conf <service> to load it.
> > > 
> > > I don't think this suggestion went over very well last time I brought it
> > > up, but recently the trend has been shifting toward narrowing our exposure
> > > to things we've tested... so I'm tossing it out one more time.
> 
> > Unfortunately this is not possible because it would break rolling
> > upgrades as I have stated in the past.
> 
> cman makes config adjustments upon seeing <cman upgrading="yes"/>, could
> it not do that for services?
> 

The cluster stack integration team can use corosync as it sees fit.

Please note the corosync dev team has no bandwidth available to deal
with rolling upgrade breakage outside of our currently tested load order
this late in the RHEL6 lifecycle.  If the cluster stack integration team
takes full responsibility for on-wire roll validation, bug fixes,
support, documentation, etc then I have no objections.

Regards
-steve

> Dave
> 




More information about the Cluster-devel mailing list