On Tue, 20 Aug 2002, Andrew Ryan wrote:
> if you want to put together some code/patches to prove my intuition > wrong, even better :) Yes, I am working on a set of modules/classes. > The above paragraph is easily implemented in mon's configuration language, > in probably ~20 lines. Yet I cringe to think about what the GUI to > represent this would look like, or whether it would even be comprehensible. I think the value of a well-designed GUI is it allows you to make fewer gross mistakes, which can lead to a lot less frustration. Although mon's configuration scheme is quite rich, a lot of the directives are simple flags or have only a few options; this is where having menus can make life much easier. The example I'm thinking of is autosys, which like mon is a scheduler, albeit for batch processing. Autosys also has its own job control language, which many people prefer, and an effective GUI for more casual use. > I do think a higher-level configuration language for mon could be useful > though. Something that would more easily allow newbies to translate > business logic into mon configs. And then a tool for going the other > direction, too, so managers and other non-mon-savvy persons can see what > the current monitoring config is in plain English I guess my real point is this: rationalizing mon's internal data structure into a hierarchy of classes with accessors could give us a consistent programming API for configuration tools. This doesn't mean throwing out the configuration file; it would just mean parsing it into calls to constructors for the class hierarchy instead of into a single large data structure. But then, instead of being limited to using the config file, other tools could be written to use that API. I also think having such a class hierarchy would make the mon scheduler code much easier to read and maintain. > Installation being more difficult than some of the other packages out there > I agree with. It would be nice if someone would write one. Yes, this is a completely separate (but important) issue. > Yeah, but you're just shifting the nasty bits around from the main program > to modules then. I just have this feeling modularity is more than a passing fad... ;) > >2) Separate the state information from the configuration > >information. This is pretty straighforward; the config file holds > >configuration information and most of the state information is stored > >by the server on the data structure in variables that begin with "_". > > I'm a little fuzzy on the benefits of this. Perhaps you could expand. This goes along with the idea of storing the configuration in the database, but keeping the state in the scheduler. It would also be possible to maintain the state in the database (autosys does this), but I think it still makes sense to keep configuration and state separate. > >3) Use an object persistence mechanism to store the configuration > >information in a database. The Tangram module > ><http://search.cpan.org/author/JLLEROY/Tangram-2.04/> would be ideal > >for this. > > I'd be interested to hear what other people think of this. I don't think an > RDBMS is needed to store configuration information, either for ease-of-use > or for scalability. If mon has scaling problems, which it certainly does > when you get into 1000's hosts I would suspect, they would be in the > runtime area, not in the configuration area. Sorry, I didn't express myself very clearly here. What a set of persistent configuration classes could give us is 1) a configuration API, as discussed above, and 2) fine granularity when making configuration changes; currently, when a change is made to the config file, mon has to reread the whole file and rebuild its configuration data structure. With a persistent set of configuration classes, a configuration change could be made to the database (via any configuration program that uses the API), and the scheduler could be told to reload a single object from the database. Dan -- Dan Urist [EMAIL PROTECTED] http://www.world.std.com/~durist
