Hello Jean, On Fri, Aug 02, 2013 at 09:25:21AM +0200, nap wrote: > We got: > * flat configuration file : purely local, but easy to hack and to know > which modules load > * discovery : great for first discovery, but erase user modifications for > regular scans (like new filesystem or new role) > * arbiter import modules : "load from what you want" is great (we got > mysql, EC2 or things like this). But can be long (think about a VMWare > dump? Or what if the source is down? (server room restart, etc etc). And
Our approach with e.g. radius is to distribute the configuration in text input form to all servers and add generated configs locally, so even after losing power and connectivity there is a reasonable config locally to start even without connectivity. The basic config is in a DVCS for easy maintenance. > Did you see that none of this allow one thing: distributed generated > configuration. Got one configuration is great, but if you got X datacenters > around the world, you will have X sources of configurations too (maybe one > datacenter is using GLPI, and another is using Itop). If you use directory based configs like in debian, an with an variable input format (like salt with yaml, python etc.) a lot can be done in my opinion already that way. But of course additional "parsing" modules from sql, GLPI etc. should be kept. > I think I found one possible solution, and I want to got your feedback > about it because it can change the 2.4 roadmap a lot. > > The key idea is to have an element that will load hosts from X sources. One > host can be filled by X sources (for example your CMDB will say > "use=production,linux" and a vmware scan will say "use=vm,europe-dc". The > element will save each source data, and will export one final version > "use=production,linux,vm,europe-dc" (we can take the source order as > priority). The important issue is how to merge and order the python objects (not only hosts) - if you allow python as config special things could be done there and must not nessessarily be introduced into the nagios syntax. > The arbiter will just have to load this final version as it's configuration > (like with an import module, not on the arbiter core code). Allowing to reload the config without restarting the arbiter(s) is the important point here - or is this already on the way and I missed it ? Having a partial reload with the same merge mechanism maybe also a good idea. > With it: > * cfg and discovery can just be sources, they will be merged with other > ones. > * skonf will also be one source (skonf will read the final version, but > will write as a priority source). > * as skonf always win, you can rescan with discovery without problems, if > the admin overload the value in skonf, it's not a problem. Beeing able to dump the python config objects into at least one text config flavour would be my dream here - then you could get a fast start with gui or automatic scanning tools while improving this later or reuse parts. > That can be a simple script, but I think we should add another daemon (yes > I know, we already got plenty...). So it can schedule regular "import", and > you can have a configuration management distribution: > > * You got one daemon on Europe, the europe admin are using a local skonf to > write into it, and you scan the europe part only. Europe guys can only see > the europe part. > * You got one daemon on Asia, the asian admin can use skonf to manage asia > hosts, and don't see the other countries. > * You got one daemon in USA... (snip) > * You got one higher level daemon (like on your higher realm) that will > "import" Europe+Asia+USA, and will output one last final version that the > arbiter will load. > > With it, you can got the same behavior for distributed monitoring, but for > the configuration management. No opinion about adding a daemon or not - the points outlined above are probaly on an other level. Just my 2 cents and as alway many thanks for your now fulltime work, Hermann -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224 Email: hermann.la...@iwr.uni-heidelberg.de ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
