Should we move component.TelemetrySettings to not be embedded?

[mx-psi]

component.TelemetrySettings is currently an embedded field in all Settings structs for receivers, processors, exporters, connectors and extensions, while all other fields in those structs are not. I believe this is just for historical reasons: we started with just the logger and to ease the transition for components we embedded the field instead of adding a top-level field.

Should we un-embed it? The main advantage is namespacing: we would avoid clashes if we want to add new fields. I feel like we shouldn't do this because:

1. It's very unlikely we would run into clashes with other fields
2. It's a bit of an annoying breaking change since it's hard to search and replace for it cleanly
3. We can't really make this change in two steps

[atoulme]

I vote to leave as is.

[TylerHelmuth]

I dont see enough end-user or component developers value in changing it now. I vote we leave it as is.

[codeboten]

I agree that we should leave this as is, I don't see the benefits in changing it.

[codeboten]

Accidentally closed 🤦🏻, reopened.

[bogdandrutu]

I would remove if not a huge deal. To do it in 2 steps I would just duplicate the data in the components Settings

Settings {
  component.TelemetrySettings
  Telemetry component.TelemetrySettings
}

And when initialize in the Service we initialize both.

[mx-psi]

Would we then do a third step for renaming Telemetry to TelemetrySettings?

[mx-psi]

I tested on #11113 this change to see the breakage. It broke 5/10 components (~50%) in core and 129/196 components (~66%) I tested in contrib (after fixing mdatagen code). Given that this cannot be fixed with a simple search and replace but rather needs going through issues one by one, I think it would be quite annoying for component developers.

I suggest we close this as wontfix.

[mx-psi]

I will close this by end of next week unless somebody has a way to make the migration easier for users.

[jmacd]

Please do not.

[TylerHelmuth]

@jmacd please do not close or please do not change?

[mx-psi]

I interpreted @jmacd as "please do not change" (as a reply to the issue title).

I am going to close this as wontfix, but it would be good to get confirmation from them (will reach out in Slack)

[jmacd]

Sorry I meant please don't change the embedding of telemetry settings-- it causes a release incompatibility for little benefit IMO. All open PRs have to rerun all the CI workflows after fixing in flight work, and I'm already spending a lot of time waiting on PRs that could merge if it were not for frequent updates and broken tests.