2011/2/23 Grégory Starck <g.sta...@gmail.com> > > 2011/2/23 nap <napar...@gmail.com> > >> Hi, >> >> >> *10 files changed, 459 insertions(+), 740 deletions(-)* >>> (better_interface)greg@brutus:~/Documents/Projets/shinken$ >>> >>> Great! :) >> >> >>> - 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: > > class Interface(..): > 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). > Ok, it will be easier to test so :)
> > > >> 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 ;) > Oh not really. Modules are just received from the arbiter, and should be launch (or relaunch). After, each module do something differrent, but the whole module management is quite the same (even in the arbiter after all). > > > >> 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)) > Maybe this hash should be compute early, with just the strings of the module definition, so if it change here, it's a new hash :) > > 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 ;) > Cool :) > > I'll look on all that for the next days/weeks, thanks for the ideas. > You're welcome :) Thanks for the commits :) I'll help you for this test cases on this part when i'll have some spare time. It's a very important part, and we do not have enouth test on it :p Jean > > greg. > > > > > ------------------------------------------------------------------------------ > 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 > Shinken-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shinken-devel > >
------------------------------------------------------------------------------ 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 Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
