On Fri, Aug 2, 2013 at 1:08 PM, Hermann Lauer <
hermann.la...@iwr.uni-heidelberg.de> wrote:
> Hello Jean,
>
Hi,
>
> [...]
>
> 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.
>
Yes, DVCS is indeed a good way to solve the configuration distributed
thing. But don't solve multi-source issue :)
>
> > 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.
>
You means like site-enabled for apache? I think put variable input format
won't give more possibilities than the current arbiter modules, but maybe I
didn't understand what you means.
>
> > I think I found one possible solution, and I want to got your feedback
> > [...]
> > 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.
>
Yes, the nagios syntax is quite limited, but as I put before, I think
"just" another templating system won't solve all problems that full-code
can.
> 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.
>
Not a full-reload, but quite the same. You will be able to compute the
whole configuration from various sources without even touch to your
arbiter. So you will be able to check it before go prod.
And think that restart an arbiter won't lock your monitoring, that's very
important :)
>
> > 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.
>
This will be possible I think.
>
> > That can be a simple script, but I think we should add another daemon
> (yes
> >[...]
> > 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,
>
Thanks for the thanks :)
Jean
> Hermann
>
------------------------------------------------------------------------------
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
