Clearly separate Config and Settings terms used in struct names throughout the codebase

[dmitryax]

trafficstars

Currently, we use the Config term for collector configuration as a whole and parts of it defined for receivers/processors/exporters/extensions. Examples:

• otelcol.Config
• component.Config
• otlpexporter.Config

But for unmarshalling some deeper parts of the user config, we use Settings structs, for example:

• [ ] exporterhelper.QueueSettings
• [x] configgrpc.GRPCClientSettings
• [x] configtls.TLSSetting

At the same time service/telemetry package still uses Config, e.g. MetricsConfig, LogsSamplingConfig, and TracesConfig.

The suggestion is to use Config term for all the structs used to unmarshal any parts of the YAML config provided by users. We will keep Settings only for structs that are populated programmatically, like:

• component.TelemetrySettings
• component.ReceiverSettings

[bogdandrutu]

I think we should start working on this, because we cannot delay until the stability.

[atoulme]

List of renames:

• [x] #9402
• [x] #9403
• [x] #9404
• [x] #9405
• [x] #9392
• [x] #9393 - on hold, might be part of bigger refactor
• [x] #9391 - on hold, might be part of bigger refactor
• [x] #9401

[TylerHelmuth]

Removing from the confighttp milestone as the public structs now use Config.

[codeboten]

Closing this in favour of https://github.com/open-telemetry/opentelemetry-collector/issues/9428

[codeboten]

exporterhelper still needs updating

[mx-psi]

We still need to update:

• exporterhelper.TimeoutSettings
• NewDefaultTimeoutSettings
• exporterhelper.QueueSettings
• NewDefaultQueueSettings

[jade-guiton-dd]

I'll work on this.

[jade-guiton-dd]

If I'm not mistaken, #11264 was the last step for this issue, so it can probably be closed.

[mx-psi]

Taking a look at the output of rg 'type \w*Setting' -tgo -i it looks like this is indeed the case :rocket: