[dev.icinga.com #12122] Template inheritance problem

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/12122

Created by spillerm on 2016-07-07 07:41:39 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-12-06 23:51:05 +00:00 (in Redmine)

---

Hi,

I noticed the following: in Director, I created a host template "generic-cisco", preview of this template is:

@
template Host "generic-cisco" {
import "generic-switch-template"

groups = [ "corporate", "network" ]
vars.is_cisco = "true"
}
@

Now I would like to add a switch, so I create an object which imports generic-cisco; the field "groups" remains empty, and even when I'm looking at the "resolved" preview, my group assignment does not appear.
So at this point, inheritance does not seem to work.

Regards,
Marianne

---

Relations:

• relates #13375

[icinga-migration]

Updated by spillerm on 2016-07-07 07:42:42 +00:00

I forgot: I'm using TODAY'S git checkout from 09:27! ;-)

[icinga-migration]

Updated by log1c on 2016-08-11 11:17:58 +00:00

I'm having nearly the same problem.
I also made a post on the monitoring-portal (in german): https://monitoring-portal.org/index.php?thread/37011-host-templates-vererben-host-gruppen-nicht-weiter/

After some trial and error I noticed the following:

If a host imports multiple templates (eg. 2), the host group of the first template is overwritten by the host group from the second template, (just as with variables).
Is it possible that the host groups are "added" instead of replaced?

Concerning your problem, Marianne:
In the example described in my forum post the host group(s) do(es) not appear in the Config-preview, although it is set. If I go to the host group view in IcingaWeb2 , the appropriate hosts are shown in their "second" host group.

[icinga-migration]

Updated by zearan on 2016-08-17 07:19:23 +00:00

I am also in strong favour of the possibility to add groups throughout the inheritance instead of overwriting them. I have both use cases in my installation: Wanting to have the groups of the parent template merged with the child and wanting to have the groups merged when using multiple inheritance.

[icinga-migration]

Updated by log1c on 2016-09-23 14:02:43 +00:00

this problem is still existent in todays git master. it would be nice if this also is fixed, though we now have the possibility to apply host groups via apply rules.

[icinga-migration]

Updated by tgelf on 2016-09-23 14:28:05 +00:00

I agree with you. Just, it's a little bit tricky, this would mean to support the following:

template Host "a" {
  groups = [ "a1", "a2" ]
}

template Host "b" {
  import "a"
  groups -= [ "a1" ]
  groups += [ "b1", "b2" ]
}

template Host "c" {
  import "a"
  groups = [ "c only" ]
}

template Host "d" {
  import "a"
  import "b"
  import "c"
}

template Host "d" {
  import "a"
  import "c"
  import "b"
}

It's missing in the schema, however a related feature already exists in the schema for state/type filters (notifications). Would work slightly different for groups, but is absolutely possible. It's also not a big issue in the code itself, this already works for notifications and has related unit-tests . But even there, this feature is only accessible through REST-API and CLI, as there are no related GUI controls.

So, the missing piece here is an element showing inherited array elements somehow within the same elements allowing one to delete some, add others and/or decide to override all of them.

In the meantime it would be nice to have a quick&dirty solution, and this could be as simple as rendering += per default, for all group properties. Unfortunately this is hardly possible right now as it has the potential to break existing configs consciously overriding groups.

Cheers,
Thomas

[icinga-migration]

Updated by log1c on 2016-09-23 14:35:47 +00:00

Hi Thomas,

thanks for your quick update! I (think) I understand the difficulties here ;).

The possibility to add groups via apply rules should be a big help in future implementations already, as of now I had to add all host groups to every host, which was a tad uncomfortable, but do-able for small setups.

If this feature is implemented in the future it would be great, otherwise I will get used to applying the host groups :)

Best regards!

Logic

[icinga-migration]

Updated by tgelf on 2016-12-06 13:05:50 +00:00

• Relates set to 13375

[icinga-migration]

Updated by tgelf on 2016-12-06 13:06:51 +00:00

I'll accept the patch in the linked issue for the next release. Hoping that there are not too many people immediately requiring -= after that ;-)

[icinga-migration]

Updated by tgelf on 2016-12-06 23:47:38 +00:00

tgelf wrote:

I'll accept the patch in the linked issue for the next release.

Seems that it won't happen so far, see linked issues for updates.

[icinga-migration]

Updated by tgelf on 2016-12-06 23:51:05 +00:00

tgelf wrote:

tgelf wrote:
> I'll accept the patch in the linked issue for the next release.

Seems that it won't happen so far, see linked issues for updates.

so far -> that fast was what I meant.

[lesinigo]

We are seeing many organizations that would really like to have this feature implemented, especially those coming from $anothermonitoringsoftware that always had it. Even without the "migrate from older software" issue, using multiple template layers that add multiple host group layers (eg. from the more generic to the more specific ones) is a really common (and IMHO good) practice.

The proposal by @Thomas-Gelf in #344 (comment) "element showing inherited array elements somehow within the same elements allowing one to delete some, add others and/or decide to override all of them" sounds like a really good solution, but the linked issue #636 seems to have stalled some years ago (!).

If it could be more feasible, I think the boolean flag proposed by @tobiasvdk in #636 (comment) could be more than enough for many people. I actually tend to advise against "exclusions" in this kind of stuff because it has a tendency to result in complex spaghetti configurations in the long term, so I usually suggest to go "append only" and such a flag would be perfect for that.

Hope this issue will get some attention in the not too distant future :-)

EDIT: for reference, this issue has also been discussed at https://community.icinga.com/t/adding-groups-through-templates/1715

[afeefghannam89]

@Thomas-Gelf ref/NC/734257

[sol1-matt]

It is also referenced on #824 with a partial solution here though that solution may have hidden issues as the partial bit is it only uses the default value which I changed from the default of assign to add.

I've been using it for around 12 months with the default set to add (so all groups I create are add) without an issue.
I'm not sure if there would have been problems if there was a combination of assign, add and remove.