RFC - Feature Template overrides Definition

[Mark Eisenblaetter]

Hi,

On Thu, Feb 14, 2008 at 1:56 PM, Andreas Ericsson <ae at op5.se> 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 214) in the
xodtemplate_clean_additive_strings funktions.

In this case i tought it would be better to rename the funktion because they
are not handling  addaptive-only anymore.

So what the "best" way to do in this case?
1. Double the xodtemplate_clean_additive_string and
xodtemplate_clean_additive_strings
2. Use the both funktions an rename them
3. Use both funktions and don't touch the name



>
> I'm not saying I'm against the idea, but if you want your patch accepted
> you need to put in at least a little effort.
>
> That's why i start to write the patch but it's my first C++ patch and my
programming skills are not the best.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20080214/c317bc1d/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel