From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Grimme Date: Wed, 6 Feb 2008 10:03:24 +0100 Subject: [Cluster-devel] rind-0.8.1 patch In-Reply-To: <1202234305.1759.196.camel@ayanami.boston.devel.redhat.com> References: <1196441345.2454.25.camel@localhost.localdomain> <200802041841.02494.grimme@atix.de> <1202234305.1759.196.camel@ayanami.boston.devel.redhat.com> Message-ID: <200802061003.24749.grimme@atix.de> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tuesday 05 February 2008 18:58:25 Lon Hohberger wrote: > On Mon, 2008-02-04 at 18:41 +0100, Marc Grimme wrote: > > Hi Lon, > > finally I had time looking at this patch and adapted your example for the > > follow-service a little bit. > > > > Besides that the eventtriggering is running es expected I stubled over > > some minor changes (find patch attached). > > > > 1. Isn't it better to organize the configuration as follows: > > > file="/usr/local/cluster/follow-service.sl"> > > follow_service("service:ip_a", "service:ip_b", > > "ip_a", 1); > > > > See below... > > > Now you can use the follow_service function as a library function and > > make the implementation in the cluster.conf (this is already integrated > > in the patch). > > > > I would also like something like this: > > > > > > > > follow_service("service:ip_a", "service:ip_b", "ip_a", 1); > > > > This would make using sl-files very modular. I didn't yet have time to > > implement it but wanted to hear what you are thinking. > > Nothing to implement, really. The following should handle both cases > without changing how configuration works (and requiring more parsing of > cluster.conf): > > > evalfile("another-lib.sl"); > evalfile("follow-service.sl"); > follow_service("service:ip_a", "service:ip_b", "ip_a", 1); > > > I do, however, need a way to set search paths for the s-lang interpreter > as a matter of configuration. (The above should work if you drop > another-lib.sl and follow-service.sl in /usr/share/cluster...) > > > > ... > Ah got it. I wasn't aware of evalfile. But wouldn't filetags work around the searchpath problem and being pretty easy to implement? > > (However, I don't consider this critical...) It's not critical but could help make the development of those sl-files more general. > > I looked in to modules, but it'd be more complicated, and it seems > import() doesn't work on RHEL (or maybe I did it wrong...). > > Note that the reason I was calling external scripts is because there's a > limit in ccsd on the amount of data you can get back from ccs_get() - > it's a couple hundred bytes. So, embedding an entire script won't work, > but a shorty script like the one you made should work. And you can independently develop sl-scripts from the cluster.conf. So you don't need a new version number anytime you change the sl-file. Besides you could build up libraries (on example is follow-service) to be used general. > > > 2. I found that the sl-function nodes_online() returns also online if the > > node in question is in the cluster but has no rgmanager running. For me > > it worked just to change the line in > > rgmanager/src/daemons/slang_event.c:606 : - if > > (membership->cml_members[i].cn_member && > > + if (membership->cml_members[i].cn_member > 0 && > > But I'm not sure if this is right. For me it worked perfectly well ;-) . > > That's strange... I'll look at that. That *needs* to work. :) Right that should not be a difference shouldn't it. ;-) > > > Next is I reimplemented your example on follow-service and made it more > > general. > > I'll take a look at it. Mine was really a PoC / example. If yours is > better, then we should document it and put it up on the cluster wiki at > some point as an example of how to make rgmanager do backflips. I just thought to make it more like a library. And I also took the failoverdomains into account when returning the nodes which are capable of running the service in question. > > > Still some cases might not be handled. But all my tests (which were > > not too many up to know) didn't show any problems. I will hand it over to > > the SAP Guys this week to let then see it this suits there requirements > > for master/slave queue replication (find the example attached). > > > :) Good good. > > -- Lon Marc. -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/