Create mapping of mainframe LPARs and VMs to host.id and host.name #3
Conversation
There was a problem hiding this comment.
For z/OS, we spoke last week about having the 4 character SMF SYSID (e.g. SYS1) for the host.name. And using a combination of the 8 Character SYSPLEX name and 8 Character SYSNAME with a delimiter as the host.id (e.g. SYSPLEX01:SYSTEM01)
An alternative to the above combination of SYSPLEX and SYNAME is to introduce a host.sysplex attribute.
Both SYSPLEX and SYSNAME can be found in system symbols.
There was a problem hiding this comment.
Looking at the spec again, it really seems like host.id should be a uuid if possible. Looking to see if I can find anything appropriate, but nothing so far.
There was a problem hiding this comment.
For host.name: For z/OS I agree that we should prefer the short, 4-character SMF ID of the z/OS LPAR. The primary reason for this opinion is that this should be most well-known name of the host, particularly for non-mainframe people, within an organization.
For host.id: I think that we can afford to provide more specific information.
For non-cloud machines and non-containerized systems, the spec states that it should be the machine-id of the host, and furthermore provides tables for the sources to use to determine the machine-id based on operating system. The table proposed in this PR seems like a reasonable extension to that precedent.
Added initial table to discuss and map mainframe LPARs and VMs to host.id and host.name.