Document host Common Runtime Attribute

[oxzi]

While being present in the attribute list for the Service object, the Host's name field is missing in the list of all attributes, even when being referred to in multiple examples of assign where.

It is also present in the REST API's response:

$ curl -s -k -u root:icinga 'https://localhost:5665/v1/objects/hosts' | jq '.results[0].name'

[julianbrost]

That attribute is not just present in Host objects but everywhere. However, https://icinga.com/docs/icinga-2/latest/doc/09-object-types/#common-runtime-attributes doesn't list it either, but that should be the better place to document it.

[oxzi]

@julianbrost: Thanks for the clarification. I found it in the Service object's documentation and copied it to the Host object as I recently missed it.
I have altered this PR to move it to the Common Runtime Attributes section and pruned it from its only other appearance in the Service object section.

[Al2Klimov]

Julian, what do you think?

[Al2Klimov]

I'm not sure whether to remove it. This one is on a per-host basis, ...

[Al2Klimov]

... but this one is unique on a per-type basis.

[julianbrost]

I mean I was somewhat surprised that the Service object actually documented the name attribute (being the only type doing that). That makes it look like you should do name = "...", so that doesn't look like the right place for that information.

There should be some place in the documentation from which you should know that services on the same host need distinct names but multiple hosts can have services with identical names (or is that too obvious to explicitly write down?), but the service attributes don't look like the correct place for that, also given that the same restriction applies to Dependency, Notification and ScheduledDowntime as well (and Comment and Downtime, but you shouldn't create those object manually).

[Al2Klimov]

That makes it look like you should do name = "...", so that doesn't look like the right place for that information.

Full ack! name=x enables you to name config objects not like config items. Which is already scary enough even if it doesn't break anything. So shall we document it at all?

services on the same host need distinct names but multiple hosts can have services with identical names (or is that too obvious to explicitly write down?

Yep.

[oxzi]

services on the same host need distinct names but multiple hosts can have services with identical names (or is that too obvious to explicitly write down?

Yep.

Which part of the logical OR question was that a yes to?

However, as the text in question is now part of the Common Runtime Attributes section, couldn't we just remove the uniqueness note?

[julianbrost]

However, as the text in question is now part of the Common Runtime Attributes section, couldn't we just remove the uniqueness note?

Yes, the text before the table with these attributes says "which cannot be modified by the user", so I mean that isn't the place you look for naming your objects anyways.

[oxzi]

Yes, the text before the table with these attributes says "which cannot be modified by the user", so I mean that isn't the place you look for naming your objects anyways.

Okay thanks. I have just pushed an updated version.