opentelemetry-collector
opentelemetry-collector copied to clipboard
open-telemetry
Decide on naming rules for `Settings` structs
Per https://github.com/open-telemetry/opentelemetry-collector/pull/9406#issuecomment-1912513732 we want to have a set of naming rules for structs ending in Settings. Current (as of 1ed45ec12569feb7863637a83b5ceefa70da44bf) 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
Createprefix fromCreateSettings? - [ ] Can we remove other prefixes (e.g.
GRPCfrom structs withinconfiggrpc,Collectorfromotelcol...)?
cc @dmitryax to fill in other rules.
Adding this to configgrpc milestone per the question above.
Very related issue: https://github.com/open-telemetry/opentelemetry-collector/issues/6767. @atoulme has been submitting lots of PRs to switch from Settings to Config where appropriate.
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.
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?
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 {
I am going to add to the otelcol milestone. Depending on #10643 we can remove it from Collector v1