[Entities] How to model host and cloud VM entities

[dmitryax]

This issue stems from open-telemetry/semantic-conventions#1752. Resolving it will also help with stabilizing the host.id attribute and fixing the following problems:

• [cloud provider] host.id semantics are too broad semantic-conventions#739
• RFC: Evolve host.id into a default, always present attribute (rethinking machine-id) semantic-conventions#581

The are three options on how we can define entities for hosts and cloud VMs:

1. Consider it the same entity

The entity will be called host, but it can have additional attributes associated with a corresponding cloud VM. We keep one identifying attribute host.id with a value taken either from the cloud provider (if applicable) or from the host machine-id.

Pros:

a. No changes to the source of host.id attribute value required

b. Keeping the entities map simple. No need for an extra relationship between the host and the cloud VM

Cons:

a. host.id stays overloaded. The value source is different depending on whether the producer has access to the cloud or not.

b. In case of 2 separate detectors (one for host, another for cloud), it would require a special merging logic that would mutate the identifying host.id attribute based on the pre-defined priority.

2. Consider them separate entities

Pros:

a. Clean separation between identifying attributes: host.id for host and cloud.vm.id (TBD) for cloud VM.

b. Easy merging logic.

Cons:

a. It requires moving the cloud VM id value from host.id to a separate attribute and keeping the host.id based on the machine-id value. This is a huge breaking change for the systems that have adopted the existing ambiguous definition of host.id attribute

b. Additional complexity to represent two separate entities. Also, it requires an additional relationship type (inherits?)

2. Consider them conflicting entities

It means that these entities cannot be present on the same resource. It has to be only one of them. The other entity can potentially be sent in a separate side channel. It'll require some special merging rule, but it'll be simpler than the merging required for Option (2).

Pros:

a. The host.id attribute overloading is not a blocking problem anymore. The cloud VM entity can keep using host.id or have a separate attribute.

b. Easier merging logic than the one required for Option (1): replacement of the whole entity instead of an attribute value.

Cons:

a. Some merging logic would still be required if separate detectors are applied.

b. Simlilar to option (2), it introduces an additional complexity to represent two separate entities.