Hello Some comments on the design below:
> * checks have to return a 4-tuple: By experience when doing similar developments in Python, create an object here. It will simplify the data handling and could be easily extended later. That's the big point. If you go for a tuple-like interface, you will be stuck with this 4-only values. Really, Python is an object language, do not hesitate to use object when needed. Regarding check, verifications, data handling, etc... If you've got an object it will be easier to add such manipulation directly in the CheckResult class. > - return code (exit status): integer > - message (status output): unicode-string, one line only > - perf-data: dict (see below) > - long status message: either a list/tuple of unicode-strings (one > line each) or a single unicode-string with several lines > separated by \n > > Missing elements have to be None. > > Rational: Nagios send strings which need to be build by the sender > and parsed be the receiver. Since shinken components talk to each > other using Pyro, Python objects can be passed around and some > overhead can be saved. > > Defining a single format of passing results simplifies handling > and saves some cycle. > > Question: should message and long status message be split al all? Or > should it be one element, a list, where the first line is the > message and the remaining lines are the long status message? > > * When running the check, these return values are not checked by the > poller for having the correct format. This forces developers to but > more care into correct code and saves some cycle. > > The base-class will have a "test(..)" method, which checks the > result types. So developers are not left alone when testing the > plugin carefully. > > Downside: cryptic error messages at the receiver, far away from the > origin of the error. > > * The base-class will have a method "as_string()" to convert the > result tuple into a Nagios-compatible string. Thus each check can be > used for Nagios. This string will be printed by the "test()" method, > too. Simply __str__() from the CheckResults object. > * The performance data will be a dict. Keys are strings, values are > either integer, float or string (percent), or a list/tuple thereof. > > Question: Do we need float results? Clearly. I see a lot of cases where float will be needed and I see not difficulties to support it. > Rational for using a dict instead of a n-tuple: a) Accessing values > is easier for both generating and analysing b) n-tuples of > 2-tuples (key, value) are a bit harder to understand for > developers c) > > Rational for not using string as values: Vales have to be parsed be > the receiver anyway. So save one there-and-back conversion. > > Rational for not using strings for lists of values: dito. > > * Errors (exceptions) within the check are caught at the place, where > the check is run. There is no need for the check to implement > exception handling. > > Rational: This simplifies development of checks and unifies how > exceptional messages are passed onto the receiver. This even > offers the option to pass the whole exception onto the receiver, > if we decide to do so some when. > > * Classes for checks will be instantiates when the config is read. This > includes setting up the option parser, parsing the command string > into pieces only once (macros will be expanded on each call, though). > > Drawback: if the code of the check needs to be changed, the > > Open questions: > > * Should we use optparse or argparse? optparse is standard since Python > 2.3 (AFAIR). argparse is standard staring with Python 2.7, but is > available for 2.4, too (AFAIK). argparse has a much cleaner interface. Developping is to ease users and make live not to hard to developers. :) So in this case, if you want to help your users, avoid for them the need to install another new python package. And I think check command line is very simple and optparse is enough for that (by the way, argparse is widely package for major distributions) Aurélien ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel