Document 'gcp.apphub_destination.*' attributes.

[michaelsafyan]

Fixes #2649

Changes

Updates the markdown docs related to GCP AppHub to document destination attributes.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• [N/A] Links to the prototypes or existing instrumentations (when adding or changing conventions)

[lmolkova]

the rule of thumb is to use . whenever it makes sense. It seems type is a property of env and (in theory) there could be multiple other properties, thus . makes sense

Suggested change

	- id: gcp.apphub_destination.service.environment_type
	- id: gcp.apphub_destination.service.environment.type

[michaelsafyan]

While this would be a reasonable suggestion in the initial design (when gcp.apphub.service.environment_type was defined), renaming here would break the rule that "for every attribute gcp.apphub.* there is an equivalent gcp.apphub_destination.* field corresponding to the destination application".

Given that gcp.apphub.service.environment_type already exists, I would like to push back on this request.

[lmolkova]

let's not define multiple attributes for the same thing.
According to docs the same enum is shared

Environment of the Application, Service, or Workload

so, can we define one and call it gcp.apphub?destination.environment.type or similar?

[michaelsafyan]

For similar reasons as the other comments, I need to push back.

I concur that there is a lot of overlap between the "service" and "workload" concepts in AppHub. Were I in charge, I would have made a single definition with "SERVICE" and "WORKLOAD" as enum types that are independent of the overall structure.

While it would have been ideal to have:

     message AppHub {
        AppHubApplication application
        ApplicationComponentType component_type  // WORKLOAD or SERVICE
        string id
        CriticalityType criticality_type
        EnvironmentType environment_type
     } 

What actually exists in AppHub is:

   message AppHub {
       AppHubApplication application
       oneof component_type {
         AppHubService service
         AppHubWorkload workload
       }
    }

... with AppHubService and AppHubWorkload having substantially similar fields. This organizational structure is carried through to the currently defined AppHub attributes (perhaps under the assumption that these fields may take on divergent meaning or values in the two contexts in the future).

The desired rule "for every gcp.apphub.* attribute, there is an equivalent gcp.apphub_destination.* attribute corresponding to the destination application" ties my hands a bit in terms of improving this organization.

[michaelsafyan]

Thanks for the review, @lmolkova . I know that I pushed back on a number of the requests here... please let me know if you are OK with me resolving those conversations or if you still consider these to be blockers. Thanks!