------=_Part_2656_12551282.1203004948858
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
On Thu, Feb 14, 2008 at 1:56 PM, Andreas Ericsson wrote:
> Mark Eisenblaetter wrote:
> > Hi List,
> >
> > in my last confusing topic I tried to explain a problem I've got with
> > configuration distribution design with nagios distributed monitoring.
> >
> > I hope to clarify this topic and present a solution.
> >
> > It would be nice if you can comment this again.
> >
> > Actual situation with Nagios 3.x:
> > If I would make my life easier with configuring nagios for my
> distributed
> > system I would define some templates to control the behavior on the
> master
> > or on the slave.
> >
> > f.e. on the slave a template would define a normal check_command, but no
> > freshness options.
> >
> > on the master server the same template name would result in some other
> > check_command inclusive freshness options and so on.
> >
> > With this possibility the service definitions on master _and_ on slave
> > servers would be identically but the different templates on both sides
> would
> > control "live checking" or "freshness checking".
> >
> > But for this it should be possible that a template made directive should
> be
> > able to override a directive from the service definition.
> >
>
> Semantically, that's anathema. Plain and simple. A template should *never*
> be allowed to override the actual object's definitions. Adding exclusions
> to that simple rule would definitely muddy the waters between templates
> and
> objects.
>
> Besides that, I really don't see the point of it. If you have different
> templates on the two servers anyway, why not just leave the options you
> want overridden in the object configuration?
>
> If you could perhaps post your templates for your master and slave and
> one or two objects that use those template, I'm sure I could explain
> how you can accomplish what you want, although I'm quite sure already
> that you'd be off just fine if you left the template-controlled variables
> out of the objects completely and set them to what they should be in the
> templates on master and slave.
Should we do this in this thread or in the initial thread?
>
> > I know that the default behavior is the other direction (template ->
> > service, but service directives are last significant).
> >
> > Since Nagios 3.x allows a template addition through the "+" notation my
> > thoughts goes in this direction.
> > What would be if you were allowed to inject a special character to your
> > template to override a service definition (for example).
> >
> > With attached patch I got exactly this behavior.
> >
>
> I failed to see the point of your patch after having scrolled past
> 4 pages of function-renaming diff data. I *do* know that it doesn't
> even compile with the attached patch. Since it doesn't compile, I'm
> thinking you can't have tested this very well at all, and what you've
> actually got running is something else, which you're not at all sure
> works as per the current spec at all.
>
Ok i will look at this. And will do more testing befor submitting the new
version.
one question is it better to patch against the last release or the last cvs
checkout.
I used the last checkout.
> It doesn't compile because you have renamed
> xodtemplate_clean_additive_string() to xodtemplate_clean_strings() and
> then call it as xodtemplate_clean_string(). That change is just plain
> noise and should never have made it into the diff. If you want me to
> review it, resend with a minimal set of changes so I can see where the
> logic happens without having to wade through page after page of nonsense.
there are both funktions in xodtemplate.c and i can't find one wrong
renaming.
I don't want to produce double code so i used addaptive funktions to provide
the Cleaning in my case.
in line 98 - 99 you can see that i added my char (=) for cleanup in the
xodtemplate_clean_additive_string funktion and added the handling of the
check_command (Host Line 199 service
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]