Decide on naming rules for Settings structs

[mx-psi]

Per #9406 (comment) we want to have a set of naming rules for structs ending in Settings. Current (as of 1ed45ec) structs that have this are the following:

Output for rg 'type ([A-Z].*Settings|Settings) struct' -tgo --glob '!internal' (click to expand)

otelcol/collector.go
56:type CollectorSettings struct {

otelcol/configprovider.go
74:type ConfigProviderSettings struct {

extension/extension.go
66:type CreateSettings struct {

receiver/scraperhelper/obsreport.go
43:type ObsReportSettings struct {

receiver/receiverhelper/obsreport.go
47:type ObsReportSettings struct {

receiver/scraperhelper/settings.go
23:type ScraperControllerSettings struct {

connector/connector.go
65:type CreateSettings struct {

confmap/resolver.go
31:type ResolverSettings struct {

receiver/receiver.go
44:type CreateSettings struct {

processor/processor.go
35:type CreateSettings struct {

config/configgrpc/configgrpc.go
51:type GRPCClientSettings struct {
120:type GRPCServerSettings struct {

processor/processorhelper/obsreport.go
59:type ObsReportSettings struct {

service/extensions/extensions.go
165:type Settings struct {

component/telemetry.go
20:type TelemetrySettings struct {

service/service.go
37:type Settings struct {

exporter/exporter.go
35:type CreateSettings struct {

service/telemetry/telemetry.go
37:type Settings struct {

exporter/exporterhelper/queue_sender.go
31:type QueueSettings struct {

exporter/exporterhelper/timeout_sender.go
13:type TimeoutSettings struct {

exporter/exporterhelper/obsexporter.go
46:type ObsReportSettings struct {

Questions that arise to me are:

• Can we remove the Create prefix from CreateSettings?
• Can we remove other prefixes (e.g. GRPC from structs within configgrpc, Collector from otelcol...)?

cc @dmitryax to fill in other rules.

Adding this to configgrpc milestone per the question above.

[TylerHelmuth]

Very related issue: #6767. @atoulme has been submitting lots of PRs to switch from Settings to Config where appropriate.

[codeboten]

I would be in favour of removing prefixes where they are duplicated by the package name and am ok with the idea of removing the Create prefix from CreateSettings.

[jmacd]

These changes are very disruptive for developers with in-flight work.
I wonder if we could evaluate the cost/benefit?
Or, could we have the deprecation schedule be longer, to give those of us with in-flight work longer to merge changes before we have to merge deprecation fixes mid-release-cycle?

[atoulme]

Clearing milestone as changes for configgrpc are done.

@jmacd most of the changes are in afaict, at least no config modules match:

confmap/resolver.go:type ResolverSettings struct {
processor/processorhelper/obsreport.go:type ObsReportSettings struct {
receiver/scraperhelper/obsreport.go:type ObsReportSettings struct {
receiver/receiverhelper/obsreport.go:type ObsReportSettings struct {
confmap/converter.go:type ConverterSettings struct {
confmap/provider.go:type ProviderSettings struct {
component/telemetry.go:type TelemetrySettings struct {
exporter/exporterhelper/obsexporter.go:type ObsReportSettings struct {
otelcol/configprovider.go:type ConfigProviderSettings struct {
exporter/exporterhelper/queue_sender.go:type QueueSettings struct {
exporter/exporterhelper/timeout_sender.go:type TimeoutSettings struct {
otelcol/collector.go:type CollectorSettings struct {

[mx-psi]

I am going to add to the otelcol milestone. Depending on #10643 we can remove it from Collector v1

[mx-psi]

Removed it from Collector v1 based on #10643