RE: [Nagios-devel] regarding upcoming features
Posted: Wed Oct 16, 2002 7:48 pm
My personal opinion is that config files should be plain old text
files for easy editing if necessary. As Subhendu mentioned, schema
redesign is not something I want to get into with each new release.
If someone wants to store config data in a db of their choice, it
would be fairly easy to create a dump of the db in a text file
compatible with the template-based config file format.
On 16 Oct 2002 at 23:36, Subhendu Ghosh wrote:
>
> A database would be nice if we could stick to a single db or perhaps just
> looking at an odbc interface. I tend to agree with Ethan about coding
> support for Postgres, MySQL, etc is cumbersome and repetitve if you have
> multiple databases.
>
> Also db tend to force a much stricter schema design and changes in data
> structures lead to a complete dump/massage/relaod cycle for upgrades which
> is a pain.
>
> With the external data interface in 2.x the goal is to enable multiple
> display applications exteremely easily.
>
> -sg
>
> On Wed, 16 Oct 2002, Mark Musone wrote:
>
> > Ideally, if the config stuff is stored in a database, everyone would be
> > happy!
> >
> > 1. external CGI's could pull in data quickly and efficiently.
> >
> > 2. The ability to expand to multiple "display applications" is
> > exteremely easy. I for one am working on a much cleaner
> > PHP interface to replace the CGI's
> >
> > 3. The ability to modify the configuration on the fly is almost
> > automatically available. Plus the ability to
> > Easly also have third party applications modify the configurations is
> > also intrinsic.
> >
> > -Mark
> >
> > P.S. oh, one other poptions that I've been toying around with is by
> > simply having a shared library that
> > Returns configuration information, makes it tremendously more expandable
> > while still having the control over
> > The configuration files.
> >
> >
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Subhendu
> > Ghosh
> > Sent: Wednesday, October 16, 2002 10:07 PM
> > To: [email protected]
> > Subject: Re: [Nagios-devel] regarding upcoming features
> >
> >
> > On Wed, 16 Oct 2002, Ethan Galstad wrote:
> >
> > > On 16 Oct 2002 at 10:28, Subhendu Ghosh wrote:
> > >
> > > >
> > > > I was going thru the upcoming features list and had a
> > > > couple of questions/comments.
> > >
> > > I just made a few updated to the page, as it hadn't been changed in a
> > > long time...
> > >
> > > >
> > > > CGI:
> > > > Even if the move to Fast CGIs is made, having the CGIs read the
> > > > object
> > > > config files directly would still cause the CGIs to be out of sync
> > with
> > > > the running monitor if the monitor was not restarted.
> > > >
> > > > Perhaps a "compiled" config created at the the start by the
> > > > monitoring
> > > > daemon would prevent the out of sync issue.
> > >
> > > Rather than creating a different format for a compiled config file,
> > > I'll just have the daemon write a single cache file containing all
> > > object definitions (in raw template format). The CGIs will then be
> > > able to read that instead of the normal config files. A compiled
> > > config file would probably be faster than the template-based ones,
> > > but using FastCGI should nullify that issue.
> >
> > cache/compile - I guess we both mean the same thing.
> >
> > >
> > > >
> > > > Adaptive monitoring:
> > > > Also if adaptive monitoring get used - some way to write out the
> > > > running
> > > > config would be useful. Otherwise a restart would loose the any
> > changes
> > > > made. Of course the argument could be made that one must modify the
> >
> > > > configs as well.
> > >
> > > Yep, the format of the retention file (and status log, for that
> > > matter) will be updated to contain current and normal settings for
> > > anything that can be changed on-the-fly.
> > >
> >
> > Well if you allow hosts and services to be added on-the-fly then we
> > might
> > obviate the need for config files for some situations!
> >
> > but small steps first
> >
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
files for easy editing if necessary. As Subhendu mentioned, schema
redesign is not something I want to get into with each new release.
If someone wants to store config data in a db of their choice, it
would be fairly easy to create a dump of the db in a text file
compatible with the template-based config file format.
On 16 Oct 2002 at 23:36, Subhendu Ghosh wrote:
>
> A database would be nice if we could stick to a single db or perhaps just
> looking at an odbc interface. I tend to agree with Ethan about coding
> support for Postgres, MySQL, etc is cumbersome and repetitve if you have
> multiple databases.
>
> Also db tend to force a much stricter schema design and changes in data
> structures lead to a complete dump/massage/relaod cycle for upgrades which
> is a pain.
>
> With the external data interface in 2.x the goal is to enable multiple
> display applications exteremely easily.
>
> -sg
>
> On Wed, 16 Oct 2002, Mark Musone wrote:
>
> > Ideally, if the config stuff is stored in a database, everyone would be
> > happy!
> >
> > 1. external CGI's could pull in data quickly and efficiently.
> >
> > 2. The ability to expand to multiple "display applications" is
> > exteremely easy. I for one am working on a much cleaner
> > PHP interface to replace the CGI's
> >
> > 3. The ability to modify the configuration on the fly is almost
> > automatically available. Plus the ability to
> > Easly also have third party applications modify the configurations is
> > also intrinsic.
> >
> > -Mark
> >
> > P.S. oh, one other poptions that I've been toying around with is by
> > simply having a shared library that
> > Returns configuration information, makes it tremendously more expandable
> > while still having the control over
> > The configuration files.
> >
> >
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Subhendu
> > Ghosh
> > Sent: Wednesday, October 16, 2002 10:07 PM
> > To: [email protected]
> > Subject: Re: [Nagios-devel] regarding upcoming features
> >
> >
> > On Wed, 16 Oct 2002, Ethan Galstad wrote:
> >
> > > On 16 Oct 2002 at 10:28, Subhendu Ghosh wrote:
> > >
> > > >
> > > > I was going thru the upcoming features list and had a
> > > > couple of questions/comments.
> > >
> > > I just made a few updated to the page, as it hadn't been changed in a
> > > long time...
> > >
> > > >
> > > > CGI:
> > > > Even if the move to Fast CGIs is made, having the CGIs read the
> > > > object
> > > > config files directly would still cause the CGIs to be out of sync
> > with
> > > > the running monitor if the monitor was not restarted.
> > > >
> > > > Perhaps a "compiled" config created at the the start by the
> > > > monitoring
> > > > daemon would prevent the out of sync issue.
> > >
> > > Rather than creating a different format for a compiled config file,
> > > I'll just have the daemon write a single cache file containing all
> > > object definitions (in raw template format). The CGIs will then be
> > > able to read that instead of the normal config files. A compiled
> > > config file would probably be faster than the template-based ones,
> > > but using FastCGI should nullify that issue.
> >
> > cache/compile - I guess we both mean the same thing.
> >
> > >
> > > >
> > > > Adaptive monitoring:
> > > > Also if adaptive monitoring get used - some way to write out the
> > > > running
> > > > config would be useful. Otherwise a restart would loose the any
> > changes
> > > > made. Of course the argument could be made that one must modify the
> >
> > > > configs as well.
> > >
> > > Yep, the format of the retention file (and status log, for that
> > > matter) will be updated to contain current and normal settings for
> > > anything that can be changed on-the-fly.
> > >
> >
> > Well if you allow hosts and services to be added on-the-fly then we
> > might
> > obviate the need for config files for some situations!
> >
> > but small steps first
> >
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]