2011/2/2 nap <napar...@gmail.com>
> Yep. But are we ok at how we manage this from the poller point of view?
>
> I don't know if we need a new check interface if we manage the PollerModule
> as a standalone worker. I think this last one sould :
>
> * have a main() like current (fork) workers, so get from a Queue Checks,
> and then run them.
> * have a run(Check) method
>
> With this, the module can be blocking or not for the call, it do not matter
> for others, and with the run(Check) call, we sill have a way to call it from
> a generic shell command.
>
> Is it ok or do you thing to something else?
>
aaahh heuh well, seems we are unsync in our understanding about this..
what I understood :
"only" move the class(es) from the bin/shinken-* to module files under
shinken/ ; I'd create arbiterdaemon.py + brokerdaemon.py +
pollerdaemon.py + reactionnerdaemon.py + schedulerdaemon.py thus..
so that all the bin/shinken-* have the very minimum code (just the "try
import shinken.Xdaemon" + adapt sys.path if needed and then instanciate the
good class and .main() on it..
no more no less.
seems like what you are referring to is something else (unrelated) that I
missed Jean.. isn't it ? and so I can continue on the above work
description.. ?
greg.
------------------------------------------------------------------------------
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
