2011/2/23 nap <email@example.com>
10 files changed, 459 insertions(+), 740 deletions(-)
- 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.
yes, and by the way I changed the interface so that they are ""async"" :
I mean for instance for the put_conf() method now it looks like something like this:
def put_conf(self, conf):
self.new_conf = conf
and that's all. have done basically the same for the others interface methods (that are possible).
and then in the different daemon (main) loops I just check for "self.new_conf != None" and then use a new setup_new_conf() method that's just basically doing what was previously in the put_conf. (at the end of this setup_new_conf there is so ofcourse the assignment 'self.new_conf = None')
It's with this change that i'm the less confident because all the codes for "conf" setup part in the different daemons wasn't very well "fixed" (for instance there was some part in put_conf but also on some others places (load_conf).
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 :)
ok good :)
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 :)
and if broker & scheduler & arbiter modules management code can be factorized along with poller&reactionner (nearly) "same" (for the "high level" goal (== just manage a pool of "modules" of it at least) code, isn't it better ?
but effectively I see there are some differences in what&how the poller+reactionner (== "pure" satellite) are doing with "modules" vs what&how broker+arbiter+scheduler are doing..
in fact theses differences here are still a bit confusing to me (in how it's actually handled in the code) and I'll need to think about it for some time ;)
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).
that's effectively a good possibility.. (cause it also can handles/takes care of changes in a module definition (like a password change or anything else than module_type and/or module_name))
If you can wrote some tests for this part, it can be good. Even simple ones, we can enhanced them later :)
hmm, yes I can ;)
I'll look on all that for the next days/weeks, thanks for the ideas.