Two methods for add/remove Hosts to Hostgroups explination?

[TBT]

Within XI, there are two ways of adding Hosts to a Host Group.

1. Within CCM, navigate to the Host, select Manage Hostgroups, add selected HostGroups.
2. Within CCM, navigate to the HostGroup, select Manage Hosts, add selected Host.

Our observation is that by using a mix of these two, elements are greyed out and need to be managed using ONE method, not a combination of both. Also, hovering over the Host will display a message stating "Object has a relationship established elsewhere" if a mix is used. When trying to remove a Host from a Hostgroup, you must use the same method that was used to add it, otherwise you're faced with a greyed out element too.

Can anyone explain the logic behind why XI forces a Host to be removed from a Hostgroup using the same method used to add it and not a combination of both?

host-1.PNG

[tmcdonald]

I don't have a good reason for why this is still the case, because I myself have asked this same question. Not being a developer though I am sure there are some issues on the backend that at worst prevent this, and at best make it a pain to resolve. I won't conjecture further.

As for why this was the case originally, I believe it has to do with how in Core you can define host<->hostgroup relationships in much the same way. The CCM tries to get as close logically to the Core config files as possible, and the backend databases need to reflect this.

[TBT]

Yeah, it's a intuitive roadblock. Perhaps you can confirm with one of the developers if this can be addressed or not?

[jomann]

Hi TBT,

The reason for this is because the CCM is a basically a configuration editor. As such, the way that it creates relationships is based on where you define things, just like if it was in a config file. Since the relationship for a host and a host group can be defined in two ways this causes a little confusion. The way it writes them is like so:

Hostrgoup -> Host (inside hostgroup.cfg)
Host -> Hostgroup (inside each individual <host>.cfg)

This is functionality that will need to stay in place for those who use it. I do agree that the CCM does a poor job of explaining at a glance why the host is grayed out in the list and has no good way to remove it without moving to the host page in the CCM to edit it. It is also hard to conceptualize that the host is actually applied when it is not in the list on the Hostgroup object since it does not show up on the right-hand side that says "Assigned Hosts" even though it is assigned to this Host Group, just done elsewhere.

As improvements are made to the CCM, I hope that we can make this type of relationship easier to understand and allow more intuitive editing of the hosts in a host group even if they aren't defined in the hostgroup definition from the hostgroup configuration page. I am not sure when this will get added though since it does require a bit of fiddling with the overall structure of how the CCM works.

[TBT]

Thank you for the explanation. We hope that this function can be improved upon in a future release as it is rather confusing, especially in a multi-user environment where it's harder to enforce how users manage network elements.

[jomann]

Not a problem, I have some ideas of how to achieve this and it should be in a minor (5.x.0) release in the future.

[gormank]

To me, adding info to hosts not related to the host is not the way to go, so this isn't an issue. My hosts have a name, address, and a template--nothing else. hostgroups.cfg contains a list of hostgroups containing hosts. Similarly, services have info about services and hostgroups are attached to services. Monitoring info is in templates since it isn't related to hosts or services.

This is how Nagios is supposed to work, but XI makes it too easy to be sloppy and define the same info repeatedly. If we had to define .cfg files for everything w/ vi, we'd learn templates in a hurry...

[jomann]

That is true, the way that I have thought of to help solve this is essentially showing that hosts are applied via a hostgroup or via a host no matter which one you are on and allowing it to remove it from the config it is applied to when removing it from the list. Essentially it'd keep the same functionality it currently has but give the user a better idea of what they are looking at. The real problem with the CCM is that it doesn't explain what it's doing as well as it could and if you've never written the files out yourself you may not know how extensive the configs for Nagios Core really are. Especially if you know what you're doing but the users who are editing them have only ever used the CCM.

[tmcdonald]

If we had to define .cfg files for everything w/ vi, we'd learn templates in a hurry...

I have said almost those exact words many times :)

And while I still agree with that sentiment, XI was designed for people who don't have the time or the knowledge of Core's syntax to configure the files by hand. If you take the flat file configs out of it and just look at it from a "I want this host in this group" perspective, then the two methods make sense - I just wish we could use them interchangeably.