Metadata type field is mapped to receiver instrumentation scope metadata and factory id

[atoulme]

We need to understand how to move forward with the use of the type metadata field. We now are trying to use it for 2 incompatible purposes:

• the type string used to register the factory

• the instrumentation library name in scope instrumentation library

          This is interesting. Is this the way we agreed to go? Maybe we should update the template to `otelcol/{{ .Class }}/{{ .Type }}` so we get `otelcol/receiver/apache`. Or `io.opentelemetry.collector.receiver.apache`, which is closer to examples defined in https://github.com/open-telemetry/opentelemetry-specification/blob/f9c26af89dcb2857772e2b75fb1318a521aa05c8/specification/glossary.md#instrumentation-library
  

cc @open-telemetry/collector-contrib-approvers

Originally posted by @dmitryax in #21272 (comment)

[atoulme]

One possibility is to change the metrics template to append the metadata class to the generated metrics code.
Another is to have another field to disambiguate and use instead of type for scope instrumentation library name.

[dmitryax]

To avoid going through 2 breaking changes, we should probably wait until #21469 is resolved

[dmitryax]

This can be resolved by setting the actuall type in metadata.yaml with what we need, like active_directory_ds and using the directory name for Scope.Name instead of metadata.yaml. This solution will work even with #21469

[codeboten]

This can be resolved by setting the actuall type in metadata.yaml with what we need, like active_directory_ds and using the directory name for Scope.Name instead of metadata.yaml. This solution will work even with #21469

If we choose to continue w/ the current, then I agree this approach could work. I supposed the thing we have to decide is whether this is the scheme we want moving forward, or if we want to go with the package name (ie. go.opentelemetry.io/collector-contrib/receiver/apachereceiver) as suggested here.

The way I see it, continuing with the current scheme means we don't have to subject users that are making use of this field today to breaking changes (at least according to #21501 it's a small subset of components impacted). That being said, the scope naming as it exists today grew somewhat organically in this repository.

A name likeotelcol/apachereceiver doesn't make it immediately clear where the producer of the data comes from. Consumers of this data would have to know that this is a component that lives in the contrib repo if they wanted to look at the code, which isn't great.

Switching to the package name does have the disadvantage of being much longer today: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/apachereceiver. Changing it to the current package name would also be a breaking change for existing users, but at least the name is more clearly stating where the telemetry comes from.

Another proposed option was to use vanity URLs to make the naming more compact: go.opentelemetry.io/collector-contrib/receiver/apachereceiver. With this change we would likely end up wanting to change the packages to use these vanity URLs as well, to reduce confusion. The downside with moving package names is that it will be a disruptive change for users of the packages and anyone who uses the builder. We may be able to mitigate some of the pain in the builder if end users upgrade to later versions that could do some package renaming under the hood.

So we have at least 3 options, with the 4th one to be nothing at all

1. Do nothing at all and live with the current inconsistency. Not use mdatagen to derive the scope name in any way 👍🏻
2. Decide that otelcol/* is the scheme we want and use the directory structure 😄
3. Move scope name to the current package name 🚀
4. Move scope name to use a vanity URL without changing package names themselves 🎉
5. Move scope name and packages to vanity URLs ❤️

Are there other options here? I'd like to agree on what we want to move forward with before we make any breaking changes for users.

[dmitryax]

I vote for 5. I'd also allow #21501 as an intermediate step to unblock #21213. It's a breaking change only for 3 components (2 alpha, 1 beta), but we can avoid that if you folks disagree, feel free to approve or reject my PR

[dmitryax]

@open-telemetry/collector-contrib-approvers, @codeboten posted a pretty important poll ^ PTAL

[dmitryax]

5 has my preference too.

Please put ❤️ in #21382 (comment) :)

[Aneurysm9]

I'd prefer option 5, but at this point I'm only comfortable with option 4 as it is unclear what the impact to users, developers and downstream distributions would be to change the package import paths. If we have a clear transition plan and can have minimal or no impact to consumers of these modules then I think option 5 is the best approach.

[TylerHelmuth]

We may be able to mitigate some of the pain in the builder if end users upgrade to later versions that could do some package renaming under the hood.

This would be really cool and would help a lot I think.