Hello again,
On Fri, Aug 02, 2013 at 01:59:05PM +0200, nap wrote:
> > 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 :)
The idea here would be different config subdirectories with different
DVCS + machine generated parts (which could be also inside DVCS trees).
> > 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.
More like crickets: All config dirs + files are read hierachical - with
a defined order added. cricket only reads a "Defaults" file first in every
dir it enters (somehow like __init__.py) - probably not needed.
Of course site-enabled is an ordering tool with a numeric prefix added, which
guaranties ordering - but is one dir only, not nested.
> > 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 important point here is to allow also python scripts as config files
(like salt) - and you will have the full power at your fingertips.
Thinking further having a config file like:
------
#py
from sql_config_shinken_module import config
return config('sqlserver.iwr.uni-heidelberg.de','user'='jean',passwd='Thanks')
-----
with returning a (list of ?) config object(s) to the arbiter for merging.
Ordering
of modules would then be expicit in the config tree.
For the object merge probably an object attribute about weight would be
helpfull.
> > 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.
As could be done at the moment with the -v to the arbiter while running the prod
arbiter.
> And think that restart an arbiter won't lock your monitoring, that's very
> important :)
Yes, but at the moment the restart resets the uptimes - which is nasty.
Maybe a config issue at our site.
> > 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.
Thanks.
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
