2011/2/23 Grégory Starck <g.starck@gmail.com>
all right :

(better_interface)greg@brutus:~/Documents/Projets/shinken$ git diff --stat master 
 shinken/daemon.py                    |   82 ++++++-
 shinken/daemons/arbiterdaemon.py     |  106 ++-------
 shinken/daemons/brokerdaemon.py      |  399 ++++++++++++---------------------
 shinken/daemons/pollerdaemon.py      |    2 +-
 shinken/daemons/reactionnerdaemon.py |    2 +-
 shinken/daemons/schedulerdaemon.py   |  242 +++++++--------------
 shinken/satellite.py                 |  360 ++++++++++++-------------------
 shinken/scheduler.py                 |    2 +-
 test/shinken_test.py                 |    2 +-
 test/test_bad_start.py               |    2 +-
 10 files changed, 459 insertions(+), 740 deletions(-)

Great! :)

as usual with changes on the core daemon codes I hope this won't break too much by everyone..

basically what's in this factorization:  

- again some Daemon code factorized (like "wait_for_initial_conf") (and now with that I think Daemon is nearly as "good" as it can be (modulo the fact that some methods should really be transformed to private methods because there are quite a lot in Daemon).

- but also and more importantly :  factorized the "pyro objects" interface  (IForArbiters, IBroks, etc....).
Oh yes, this was quite indeed a lot of code duplication here. 

I'm finishing some further manual tests (actually end_to_end + quick_tests are already good) on this and then I will push that normally later today..
Ok. There are not a lof of automatics tests for this part, just the end to end and yours if I'm not wrong, but it's quite small, nearly each calls are just bypassing the call to real daemon, so there should not be real problem here, and we have time to test :) 

it's more than possible that some last clean or simplification or correction will be needed there and there after that..   eventually also for some attribute rename but not that much.

By the way, still on this matter of code factorization :  I see that the modules management code (when a daemon receives its modules in a (new) conf from arbiter(or scheduler)) is not very "good" (imho) :  nearly every daemon manages that in a different way (and not necessarily 100% robust) ;  I think that it is also possible to factorize/handle that quite better..  but that won't be for these days ;)
Yes indeed. Poler/reactionner should be the same, but it's the only ones :)

I think we should look at a "module hash" so the daemon can see if the modules it got are already initialized or not (and so on load module initialization, that the broker can't do from now).

If you can wrote some tests for this part, it can be good. Even simple ones, we can enhanced them later :)

just to check : Jean do you see what I mean here ??  will it be good to factorize/clean that also ?
Yes :)

Thanks a lot for this, :)



Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
Shinken-devel mailing list