David Nolan <[EMAIL PROTECTED]> writes:
> Ewww.. m4. Uh, I mean, ooh, thats kinda neat. :)
> I wonder how well m4/mon handles it when the esyscmd program
> takes a long time to return, or just fails. I suspect not
> well, at least during a config reload.
> NetSage generates the config files on its own, and then runs
> a script that copies it into place, asks Mon to test the
> file, and assuming it passes the test tells mon to reload.
> An m4 macro that dynamically generates the contents sounds
> like it would make the 'test and reload' operation both
> expensive, and unpredictable, since the file would be
> generated twice, and not guaranteed to be the same.
There's obviously more elegance and probably reliability to your
approach. However, couldn't you do the same thing with the m4 step
aside from Mon? ie you have m4 create the file, test that file, then
load that file if ok. You wouldn't necessarily have to do the m4
pre-process at Mon load.
I've long used the Mon/m4 syscmd approach with a Rocks cluster to
query the node names from MySQL and assign to a Mon hostgroup. I
have Mon invoke m4 directly with -M and I've never had a problem in
this limited scope. More complicated configs might be a different
story. A full database generator would obviously be more powerful.
Jerry
_______________________________________________
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
