Pablo Baeyens

From Datadog's side, the datadog processor was removed on v0.94.0. I am also proposing we remove the spanmetrics processor later this month.

We discussed a way to speed this up that we can tackle as a last resort: we could remove the `component.Host.GetExporters` method from the `component.Host` implementation, but still have the...

Moving to service 1.0 after #9987. The remaining part is to remove in contrib components and then remove from the service's `component.Host`.

> but may break some users so we need to find a way to handle/communicate that. We may want to have some sort of subcommand/flag/separate tool to migrate a config...

See #7631 :)

Per https://github.com/open-telemetry/opentelemetry-collector/issues/8215#issuecomment-1865028717 before doing this we need to add support for `${...}` to the general expansion before removing this converter, to align with https://github.com/open-telemetry/opentelemetry-specification/pull/3744

IMO `BuildInfo` does not make sense in `service`: the components should not know anything about the service other than through the `component.Host` interface; ideally we should be able to completely...

I am wondering if we should split `component` into further packages. For example, we could have `componentstatus` and `componentfactory` as separate packages. It currently feels like a mish-mash of important...

The Collector supports recursively expanding `${env:...}` and the legacy `$ENV` syntax in the contents of an environment variable, so you need to escape the `$` as documented on [the official...

I moved this to opentelemetry-collector since this is not specific to the postgresql receiver, but rather applies to configuration more generally. I think this would not happen if the [expandconverter](https://github.com/open-telemetry/opentelemetry-collector/tree/main/confmap/converter/expandconverter)...