Errors in Nagios configuration templates parsing

[mohierf]

As I explained in this Alignak issue: https://github.com/Alignak-monitoring/alignak/issues/371, the templates parsing made by Shinken is erroneous regarding to what is defined in the Nagios documentation found here: https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/objectinheritance.html

Shinken only considers that an object is a template if it is not registered (register property is set to 0) whereas Nagios considers that a configuration element is a template when it finds a name property, It can even be a template and a real monitored object.

[geektophe]

In fact, it was a deliberate decision to dissociate templates from final objects. Internally, it is not treated the same way, and it would add some more complexity in the configuration parsing to handle this case.

Changing the way templates are detected is pretty easy (presence of the name attribute rather than setting register to 0), but managing final objects that can also be templates is a more complex feature (despite it may be thought at first sight).

On the other hand, using register set to 0 as template identification condition has the advantage to clearly make the difference between templates and final objects, which make the overall result clearer (at least from my point of view).

We can consider sticking to Nagios behavior, but we have to know if this is a real requirement because many people depend on this behavior, or if it's just to advertise we're compliant.

[mohierf]

I hear your comments and I do agree with them.

I am involved in the Shinken project since some few years up to now and I always heard about Nagios compatibility. This is clearly advertised as soon as you mention Shinken. This is why I was quite disappointed when I found this difference between Nagios and Shinken/Alignak configuration parsing because it raised some errors :disappointed:

I am sure that this tricky Nagios feature and the deliberate choice you mention is somewhere in the doc. What is also sure is that it will not help Nagios users to migrate easily

[geektophe]

If you think this is an obstacle to the adoption of shinken, why not having an eye on it.

So the basic idea would be:

• Template detection is made on the presence of the name attribute rather than having register set to 0
• If the object has a naming attribute, such as host_name, contact_name and so on, create both a template and the terminal object.

The tricky part is often services management, and particularly decide how to handle those generated from duplicate_foreach expression if they are not register 0.

I'll try to have a look at this when I'll have free time.

[naparuba]

Hi,

I think backport this bug from Nagios won't be a great thing. I think the real problem is that we don't refuse/error such objects by letting the user know that nagios spec is really error prone here and we choice do not follow it (like we did change the inherit_parent default value for dependencies).

The real point here is that I think we should switch from all the host_name, contact_name, XXX_name property to just "name" and let the "register 0" expose it as a template or not. Will be far more easier for user to understand with far less errors.

All my customers that try to wrote cfg file did fail in this by just put "name" and just use register to know if it's a template or not. It's the obvious way for them, but it's not the nagios one.

One other way can be also to have a new "define host-template {" that can be just so clear for every one.

So let take from the other side: let put aside Nagios: what is the most clear way for user to define an host and a template, and be sure he/she is doing the right thing? :)

On Thu, Sep 29, 2016 at 8:59 AM, Christophe Simon notifications@github.com wrote:

If you think this is an obstacle to the adoption of shinken, why not having an eye on it.

So the basic idea would be:

• Template detection is made on the presence of the name attribute rather than having register set to 0
• If the object has a naming attribute, such as host_name, contact_name and so on, create both a template and the terminal object.

The tricky part is often services management, and particularly decide how to handle those generated from duplicate_foreach expression if they are not register 0.

I'll try to have a look at this when I'll have free time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/naparuba/shinken/issues/1871#issuecomment-250386308, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbLjXnVlKnnIvrlfT0cDgHSy3vx_z01ks5qu2HPgaJpZM4KHnB_ .

[mohierf]

I do agree with both of you :)

[geektophe]

I like this idea !

Shinken also has unique features that do not exist in Nagios. Let's advertise on them rather on full Nagios compatibility.