From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Grimme Date: Wed, 6 Feb 2008 20:18:00 +0100 Subject: [Cluster-devel] rind-0.8.1 patch In-Reply-To: <1202317294.21504.50.camel@ayanami.boston.devel.redhat.com> References: <1196441345.2454.25.camel@localhost.localdomain> <200802061003.24749.grimme@atix.de> <1202317294.21504.50.camel@ayanami.boston.devel.redhat.com> Message-ID: <200802062018.01002.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 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: > > > > > > > > > ... > > > > > > > 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: > > > > > script_body(); > > > instead of: > > > evalfile("/rgmanager/slang-scripts/foo1.sl"); > evalfile("/rgmanager/slang-scripts/foo2.sl"); > script_body(); > 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/