This is a really good enhancement point. One ring to rule them all ;-). But
i have one question. You say skonf always win, but what if we do not use
skonf ? In this case could it be possible to specify a weight for each
source ? Or may be allow each source to have a weight (also for skonf).
2013/8/2 nap <napar...@gmail.com>
> Hi,
>
>
> I was looking on the monitoring configuration management side lately, and
> I think we got lot of enhancement possible there.
>
> 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
> one host can be export by one module **ONLY**
> * Last but not least: Skonf. Graphical is great, but can't write into
> flat files, just read/write one source (mongodb). Also inherit the
> discovery problems. This sucks, and that's why I stopped it.
>
> 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).
>
>
> That's why I think we got lot of enhancements there.
>
>
> 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 arbiter will just have to load this final version as it's
> configuration (like with an import module, not on the arbiter core code).
>
> 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.
>
> 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.
>
> I'm thinking about giving the name of "shinken-synchronizer" (or something
> like shinken-sync), because it syncronize X sources.
>
>
> So, what do you think about it? It it clear enough? Did I miss something,
> or it it "too much"?
>
> It's your turn now :)
>
>
> Jean
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
