Tracy R Reed wrote: > > So I'm somewhat new to the OO thing and somewhat new to python and I am > writing this program to work with nagios. Basically there is a client > part that runs on all of my servers which reports load average, disk > usage, etc. etc. back to the server. The server then looks at these > values, compares them with what is expected, and tells nagios whether to > start paging or whatever. So if a filesystem is 90% full it's a warning > and 95% full is critical etc. I am trying to decide how to implement > configuration for this. I would like to have some default values which > are used if nothing in particular is specified. Sometimes on a really > huge filesystem which grows slowly maybe 99% is good enough for a > critical warning so we will specify that as a threshold instead of > letting it use the default. > > Here's the code as it stands so far: > > http://www.pastebin.ca/351709 > > So far just really basic. The config doesn't even work yet. I am > wondering how to do this still. At first I was going to just create a > config.py file and import it and it would contain all of the values. It > seems that I need to store a hostname, service name, and pair of > threshold values. But I didn't want to have to search a list of lists > for the hostname of the server I am currently talking to. So I thought I > would use a dictionary. But then I get a dictionary of dictionaries > situation which is really hard to maintain because I find myself > becoming confused over where I need a brace, where I need a paren, where > I need a comma, etc: > > config = {"djutil01" : {"report_load" : (2,4), "report_disk": (90,95)}, > "djutil02" : {"report_load" : (2,4), "report_disk": (90,95)} > } > > This is intended for others to use eventually so maybe that's not such a > good idea. How about a list of lists? Same problem plus I have to search > through the list to find the one I need which seems like a pain. Maybe > there is a smarter OO way to do this? Seems like it would be nicer to be > able to refer to config parameters using actual names instead of > config[hostname][service][0] and so on. Maybe I could have some sort of > configuration objects which I create by reading in some sort of csv file: > > djutil01,report_load,2,4 > djutil01,report_disk,90,95 > djutil02,report_load,2,4 > djutil02,report_disk,90,95 > > etc. and then I can store each of those config objects in a dictionary > and make each of the config objects inherit from some sort of default? > Something like: > > class ServiceConfigDefault: > load_warning=2 > load_critical=4 > disk_warning=90 > disk_critical=95 > > class ServiceConfig(ServiceConfigDefault): > def __init__(self, **kwargs): > service = kwargs["service"] > if kwargs["load_warning"]: > load_warning=kwargs["load_warning"] > if kwargs["load_critical"]: > load_critical=kwargs["load_critical"] > > > And then as I read the data from the config file I can instantiate a > ServiceConfig object and stick it in a dictionary keyed by the hostname. > But this seems less than flexible also. Having that if test and then > assignment if it is not set seems clumsy. And I'll have to add a test > for each possible config option. But at least this should get the > default if the thing isn't defined. > > Also, I will probably get into configuring things which are different > than hostname, threshold, and a pair of integer threshold values. So > perhaps I should be able to have a different sort of service object > depending on what it is exactly that I am to be monitoring. For example > I will want to be able to monitor that a certain process is running. > That won't have a pair of integer threshold values but will instead have > a string to search the process list for. Currently this config resides > on the server side. But I think perhaps I will want to push it to the > client side instead because I'm not going to pipe the whole process list > over to the server. The client needs to know what process to be checking > for. But even if I do that the same config questions will remain. > > After thinking about this OO stuff for a bit the first option of using > dictionaries of dictionaries isn't seeming so bad as far as complexity goes! > > Back when I first conceived of this program I thought I knew just how I > would do it but now that I'm actually writing code I'm lost! > > Thoughts? >
Whatever you end up with, I strongly urge minimizing structure, especially nesting. I think the good-ol' ini file format has a LOT of headroom. And sections containing tuples map nicely into hashes/dictionaries. I believe there is a lot of good published code to deal with ini file reading and writing. - I would probably ensure that whitespace is tolerated at start/end-of-line and surrounding the '=' - I would _consider_ the need for multi-line data or data containing significant leading/trailing whitespace - If updating from user input, I would consider allowing and preserving comments I don't know that that there is a clear requirement for objectification, but it certainly seems good to encapsulate the interface in a module. I suppose the sections could just as well be object member elements, and maybe that would make it convenient to model the configuration 'cascade'. The shell way of cascading configuration settings seems quite versatile factory defaults system wide values user specific values one-time (command line or script) values Each successive dataset overrides and extends the prior one. A syntax/mechanism may be needed for prescribing non-overridable values, too. As you know, python, or perl can (and probably anything else can be arranged to) replace or extend dictionary/hash entries, making the inheritance concept pretty simple. If [when] you need to provide a user-interface for finding, browsing, setting config data, then the simplest structure pays off in a more intuitive UI. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
