[Cluster-devel] rind-0.8.1 patch

[Marc Grimme <grimme@atix.de>]

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:
> >   <event name="followservice_node" class="node"
> > file="/usr/local/cluster/follow-service.sl">
> >                         follow_service("service:ip_a", "service:ip_b",
> > "ip_a", 1);
> >     </event>
>
> 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:
> >   <event name="followservice_node" class="node">
> >         <file="/usr/local/cluster/another-lib.sl">
> >         <file="/usr/local/cluster/follow-service.sl">
> >         follow_service("service:ip_a", "service:ip_b", "ip_a", 1);
> >     </event>
> > 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):
>
>   <event name="followservice_node" class="node">
>     evalfile("another-lib.sl");
>     evalfile("follow-service.sl");
>     follow_service("service:ip_a", "service:ip_b", "ip_a", 1);
>   </event>
>
> 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...)
>
> <events search_path="/usr/share/cluster:/usr/local/cluster:..." />
>    <!-- for example -->
>    ...
> </events>
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/