On Fri, Feb 1, 2013 at 8:56 PM, Olivier Hanesse <email@example.com>
2013/2/1 David GUENAULT <firstname.lastname@example.org>
well i agree with packaging (for industry class deployment) but i do not think install script is uselless because it help setup a fully featured solution in minutes and help quickly discover the potential of shinken.
I think "apt-get install shinken" will always be easier ;)
For Debian/Ubuntu (and maybe others distros), we should focus on hosting our own repository, with up-to-date packages. This way, install will be easier and ready for industry.
The install script should be useful for easy repository configuration for example, and things like that.
Discovery is a really great tool and should survive the game. But it should integrate more than a way to do it (for example discovery process should be able to plug on various systems such as CMDB or inventory tools like fusion inventory). And that is already done, we just need to make it easier to extend (at least better documentation).
What about developing arbiter modules for cmdb instead of a discovery plugin for it ?
The key is dynamic load versus load then cache/modify.
With discovery, we can (easily) discover hosts and data, apply the rules, and we save them (whatever where and how, we don't care here). Then we can look at them and edit them.
With arbiter modules, we do the load each restart. One good point is that we are always "uptodate" from the source. A problem is that we can't review/modify hosts before add them in the configuration.
Maybe a solution can be to have better "rule" based arbiter modules. We know that with templates, we got lot of capabilities if the hosts are filled like they should with all "properties" (name, ip, but also ssh ports and things like that). We will never have a perfect arbiter module that will got all of theses data, never. But a way can be to allow hosts to be "merged" into the arbiter before being launched. Currently, if we got two hosts objects with the same name, the laster will be lost. Why not just merge them? Modules can just give the host with the data they know about (Vmware will have some tags to add, Active directory will have another, etc).
So we can have the multi-source thing from the discovery, and the dynamic thing from the arbiter modules.
The good thing for dev : we got all we need for the arbiter module parts in fact ,we just need to add a pass about the host merge, that's all :)