Add message about available components to AgentDetails #201
Conversation
specification.md
Outdated
| "github.com/open-telemetry/opentelemetry-collector-contrib/receiver/[email protected]": { | ||
| "metadata": { | ||
| "type": "hostmetrics", | ||
| } | ||
| } |
There was a problem hiding this comment.
The ID here works for how everything is structured in contrib. I'm wondering if you could cause a collision through, simply by having multiple components in one module? Do we need to support that? I don't think the builder supports that case currently, either.
There was a problem hiding this comment.
Technically the builder does support this, though I don't think it's frequently used. If components are hosted under different paths inside the same module, the builder can be told to include a component per package. That is, if the module is github.com/open-telemetry/opentelemetry-collector-contrib, the path could be receiver/hostmetricsreceiver or processor/transform for the package within the module where the component is found. I think it's safe to say that these could be reported as github.com/open-telemetry/opentelemetry-collector-contrib/[...]@vX.Y.Z, though I'm not sure how this is currently handled in the Collector's reporting of each module.
If that's accounted for, the builder limits each path/package to a single component, so we're okay from that perspective.
There was a problem hiding this comment.
This is a good point.
I inverted the ID to be the type string instead; I think the type should be unique within it's class (e.g. there is only one "hostmetricsreceiver" in any given build of the agent). Then the module is in the metadata as extra information to identify the exact version of code.
|
@andykellr @tigrannajaryan Here's a rough draft of ComponentDetails, when you get a second to take a look. |
|
@tigrannajaryan friendly bump on this |
Sorry for the delay. Reviewed. |
|
@BinaryFissionGames please ping me once this is updated to reflect our last discussion in #198 |
specification.md
Outdated
| "github.com/open-telemetry/opentelemetry-collector-contrib/receiver/[email protected]": { | ||
| "metadata": { | ||
| "type": "hostmetrics", | ||
| } | ||
| } |
There was a problem hiding this comment.
Technically the builder does support this, though I don't think it's frequently used. If components are hosted under different paths inside the same module, the builder can be told to include a component per package. That is, if the module is github.com/open-telemetry/opentelemetry-collector-contrib, the path could be receiver/hostmetricsreceiver or processor/transform for the package within the module where the component is found. I think it's safe to say that these could be reported as github.com/open-telemetry/opentelemetry-collector-contrib/[...]@vX.Y.Z, though I'm not sure how this is currently handled in the Collector's reporting of each module.
If that's accounted for, the builder limits each path/package to a single component, so we're okay from that perspective.
…ave the AvailableComponents message
|
Looks like a link is broken unrelated to the changes in this PR, but this should be good for another look. |
Co-authored-by: Evan Bradley <[email protected]>
|
@andykellr or @dpaasman00 will you take over this PR to make the final fixes before merging? |
Yes, I just pushed changes based on your feedback. It should be ready. |
This PR adds a new ComponentDetails type that allows agents to communicate metadata relating to the components available in the agent.