DB store for cfg data

[local.coder]

Ethan has said that he saw DB storage as a module. An option to be put in place.
In 2.0 we should see a common set of functions and classes for pushing the data
into nagios and pulling host status data and entries from nagios.

This will eventually be tied to "name your DB" and frontend for working with
hosts. There are several times when I cures the text files, but there are
others where I can add strange things quickly and easily. I know that setting
up the right DB to give me the same functionality will be difficult. Things
like having all the possible options but just setting the basics and still
allowing flexibility. I am a DB person by work and even I can see why Ethan
wanted to stay away from it on this. DB alone would take all the time and
effort to tweak and make work right.

2 things are certain. We will see a web interface for configuring Nagios and we
will see a way to store all the data in a DB. It's all about when and who.

Derrick

Quoting Andreas Ericsson <ae at op5.se>:

> Ed L. wrote:
> > I'm looking for a suitable monitoring system, and have recently spent some
> > time evaluating Nagios.  I notice that 1.2 appears to have some support for
> > local storage of cfg data (eg., hosts, groups, contacts, dependencies) in a
> > relational database (pgsql/mysql) as opposed to the flat files in
> > nagios/etc/*.cfg.  A brief glance at the cvs logs since 1.2 seems to
> > suggest it's all been gutted long ago (Dec 2002?), and also appears to be
> > removed from the latest configure script on the cvs trunk.
> >
> > Is there a current nagios developer consensus on the value of cfg storage
> in
> > an RDBMS?  Not worth doing?  Others working on it?  Is it desired?
> >
>
> I think it was axed due to the problems involved in normalizing the
> database for the nagios configuration.
>
> To get the nagios config to 3NF would require a herculanean effort, and
> nobody seems willing to do it until there's a decent web-interface to
> set up the configuration anyway. Ofcourse, it's impossible to write the
> web-interface without having the layout done, so the breakdown comes
> full circle before we even gained momentum.
>
> Besides, adding support for one type of RDBMS would soon raise voices to
> add support for others as well, and that means even more work without
> actually adding functionality.
>
> The GUI for Nagios 2.0 is a whole lot faster anyways (hashing code,
> cached static form object data), so performance is not really an issue,
> and most users are more comfortable with emacs, vi or regular
> expressions than with sql queries for updating their config.
>
>
> > TIA.
> >
> > Ed
> >
>
> --
> Sourcerer / Andreas Ericsson
> OP5 AB
> +46 (0)733 709032
> andreas.ericsson at op5.se
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND