Added support for distribution config in ConfigProvider

[robsunday]

Fixes #4770

This PR introduces Declarative Configuration support for distribution specific configuration.
The .distribution node is now available in the root of Declarative Configuration YAML file, as agreed on SIG.

Changes

ConfigProvider is extended with new operation to provide access to the .distribution node

For non-trivial changes, follow the change proposal process.

• Related issues #opentelemetry-configuration/issues/336
• Related OTEP(s) #
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
• Spec compliance matrix updated if necessary

[carlosalberto]

cc @jack-berg

[trask]

the link points to the .instrumentation node

[jack-berg]

All instrumentation will have access to this. The original design of ConfigProvider intentionally limited the scope to the .instrumentation/development node, so as to avoid the questions about whether its appropriate / safe for instrumentation to have access to the SDK config model, including any secrets that may be present on the exporter nodes.

If we want to broaden scope, we need to have that conversation since its very reasonable that .distribution node will have the types of secrets that are in the SDK config model.

On a related note, why is this necessary?

The declarative config has separate parse and create methods that allow a distribution to access the .distribution node. For example in java:

OpenTelemetryConfigurationModel model = parse(new File(System.getEnv("OTEL_EXPERIMENTAL_CONFIG_FILE")));
DistributionModel distribution = model.getDistribution();
OpenTelemetrySdk sdk = create(model);

If there's not a strong need for this, the safe answer is to continue the status quo and not grant instrumentation access to more config than they need.

[robsunday]

I'm sorry for the delayed response—I was on vacation.

ConfigProvider exposes instrumentation configuration in a clear and consistent way for all languages. I wanted the distribution configuration to be exposed consistently among languages as well. I believe this would be very beneficial, which is why this PR was created.

Regarding the recommended alternative approach, I see some issues with it:

1. It does not really improve security over the ConfigProvider extension. Extracting secrets from the declarative config file is still possible when calling the parse method, right? At the same time, it complicates life for honest developers.
2. The Java example above is problematic for Otel Java Agent-based distributions that need distribution configuration settings in AgentListeners. The SDK is configured from AgentInstaller without any extension hooks that could be used, so the config file would have to be parsed again in each listener to extract DistributionModel. Of course, we could create a dedicated AgentListener that parses the config and stores it in some static variable, but in my opinion, that starts to get tricky.
3. It will lead to inconsistent implementations among languages.

[robsunday]

Ad 2 - instead of dedicated AgentListener we could use custom DeclarativeConfigurationCustomizerProvider that takes DistributionModel from OpenTelemetryConfigurationModel and then stores it in some static field, so it can be used later on. I still think that ConfigProvider solution is better in terms of clarity and standardization.

[zeitlinger]

@robsunday I have implemented exactly what you suggested - and only saw your comment now.

My takeaway was also that it starts to get tricky with statics - see open-telemetry/opentelemetry-java-instrumentation#15822

[jack-berg]

Requesting changes because I want to make sure we discuss this before merging.

[lmolkova]

@robsunday could you please work with Java SIG on unblocking your work and trying out alternative proposals?

I think @jack-berg's SDK / API separation argument is good, and I believe his example of how we can access distribution configuration should work for the OpenTelemetry Java agent distribution. We can always come back if we run into further issues.

[robsunday]

@robsunday could you please work with Java SIG on unblocking your work and trying out alternative proposals?

Yes, however I still have some comments for this PR