From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christine Caulfield Date: Thu, 28 Jan 2010 09:11:06 +0000 Subject: [Cluster-devel] skipping unused services, cman_tool join -A In-Reply-To: <20100127213800.GC21005@redhat.com> References: <20090925192752.GD14664@redhat.com> <20100127204924.GB21005@redhat.com> <1264625498.2569.31.camel@localhost.localdomain> <20100127213800.GC21005@redhat.com> Message-ID: <4B6154AA.10806@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 27/01/10 21:38, 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 >>>> >>>> >>>> >>>> >>>> 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 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, could > it not do that for services? So, let me get this straight. For a cman upgrade you want to load the same services as before. But for a new full-featured RHEL6 cluster suite you think we should load fewer services, thus removing features ? To me it seems like a pointless bit of added complication, for us and users. If the service is still to be shipped then what do we gain by simply making it more difficult to use? So far Perry's argument is that we don't *ship* things we can't support, thus preventing people from using them at all unless they compile it themselves. But this is different in that we have to ship the openais modules anyway, so disabling them is merely being wilfully obscure. It's a bit like shipping a command-line tool that was in RHEL5, but on RHEL6 insists on having the first parameter "PLEASE" before it will do anything. I'm not really passionately in favour of either way, I just don't see any benefit to us, or (more importantly) to customers, from changing it. Chrissie