[Cluster-devel] rind-0.8.1 patch

[Marc Grimme <grimme@atix.de>]

On Wednesday 06 February 2008 18:01:34 Lon Hohberger wrote:
> On Wed, 2008-02-06 at 10:03 +0100, Marc Grimme wrote:
> > On Tuesday 05 February 2008 18:58:25 Lon Hohberger wrote:
> > > <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?
>
> I don't see searchpaths as a problem, and in fact, I might not have to
> fix it anyway (yay!).  Turns out, this works, too (I thought it didn't
> for some reason):
>
>   evalfile("/tmp/lon.sl");
>   lon_function();
and the evalfile could also be use in sl-files I suppose.
>
> /tmp/lon.sl:
>
>   evalfile("/root/foo.sl");
>   define lon_function()
>   {
>     foo_function();
>     printf("Hello, world!\n");
>   }
>
> /root/foo.sl:
>
>   define foo_function()
>   {
>     foo_function();
>     printf("Test\n");
>   }
>
> > > (However, I don't consider this critical...)
> >
> > It's not critical but could help make the development of those sl-files
> > more general.
>
> Given that absolute paths also work, does this satisfy the requirement?
> I really can't see adding more parsing code for something S-Lang already
> does.
>
> I mean, it's not -that- hard to add, but it's kind of pointless to do:
>
>   <event>
>     <file "/rgmanager/slang-scripts/foo1.sl"/>
>     <file "/rgmanager/slang-scripts/foo2.sl"/>
>     script_body();
>   </event>
>
> instead of:
>
>   <event>
>     evalfile("/rgmanager/slang-scripts/foo1.sl");
>     evalfile("/rgmanager/slang-scripts/foo2.sl");
>     script_body();
>   </event>
Yes, this way is better I agree.
>
> > > 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.
>
> That's also a benefit (and using evalfile() in your code instead of
> embedding the equivalent in cluster.conf also is coincides with this).
>
> > > > +               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. ;-)
>
> Definitely not. :)
>
>
> One thing I think's missing is intelligence about event collapsing in
> default_event_handler.  For example, if a service fails and you restart
> it, but restart fails, so you move it to another node (all in a single
> event handler execution), we get 5-ish events for that:
>
>  * failure event
>  * stopped event
>  * start event
>  * stopped event
>  * start event
>
> The middle 3 events become irrelevant.  We could fix it in
> default_event_script.sl by checking the current state and if the current
> state doesn't match the event, throwing it out.  (I think throwing them
> out for user-defined event scripts is a bad idea, however, which is why
> I suggested changing it in default_event_handler).
>
> This could also be a good 'library' function (as could several of the
> functions in default_event_handler.sl).
Yes and therefore be useable with evalfile and everything.

But I like those eventscripts. Especially when they don't complicate the 
cluster.conf files.
>
> -- Lon

Marc.

-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/