Discuss migrating dynamic-control from ConfigProperties to DeclarativeConfigProperties

[zeitlinger]

Summary

dynamic-control still uses ConfigProperties internally in a few places, and a follow-up idea was to replace those usages with DeclarativeConfigProperties.

That needs design discussion first.

Why discuss first

A key concern is that the current TelemetryPolicySamplerComponentProvider path uses SystemPropertyFallbackConfigProperties, which manually reads from system properties / env vars.

That is important because it violates the spirit of dynamic-control's declarative config path: when dynamic-control is configured through declarative config, we should be very clear whether it is supposed to honor only the declarative config model, or whether it is also allowed to reach out to unrelated system properties / env vars on its own.

A naive migration away from ConfigProperties risks either:

• preserving behavior that we may not actually want to preserve, or
• accidentally changing behavior without first agreeing what the intended behavior should be.

So before changing dynamic-control to use DeclarativeConfigProperties throughout, we should clarify:

• whether dynamic-control should manually read system properties / env vars at all in declarative-config mode
• which config in dynamic-control is intentionally declarative-only
• whether any fallback semantics are intentional, accidental, or need to be split by use case
• what the desired API shape is for sources/providers such as OpampPolicyProvider

Scope candidates

Potential follow-up work after agreement:

• TelemetryPolicySamplerComponentProvider
• PolicyInit
• SourceKind
• OpampPolicyProvider
• related tests

Context

This came up while reducing deprecated DeclarativeConfigPropertiesBridgeBuilder usage in:

• Replace declarative config bridge usages in contrib #2988

[zeitlinger]

@jackshirazi did you intend to work around the design of declarative config here?

[jackshirazi]

There are three possible configurations. All three need to be supported:

1. No declarative config and no config provider. This is handled by the old autoconfiguration
2. Both declarative config and associated config provider. This is handled by the TelemetryPolicyDeclarativeCustomizerProvider and TelemetryPolicy*ComponentProvider (currently only Sampler component). Because the telemetry policy is in the declarative config, the config is read purely from the declarative config, the fallback isn't used
3. No declarative config is present but a config provider has been instantiated so is supplied and consequently the declarative config path could be used. In this configuration we need the fallback

[zeitlinger]

2. Because the telemetry policy is in the declarative config, the config is read purely from the declarative config, the fallback isn't used

This is the only case where the fallback is used

opentelemetry-java-contrib/dynamic-control/src/main/java/io/opentelemetry/contrib/dynamic/TelemetryPolicySamplerComponentProvider.java

Lines 39 to 45 in e3fefc2

	public Sampler create(DeclarativeConfigProperties config) {
	logger.log(
	Level.INFO,
	"Dynamic control extension has been loaded by the agent via declarative config");
	ConfigProperties bridgedConfig =
	new SystemPropertyFallbackConfigProperties(
	new DeclarativeConfigPropertiesBridgeBuilder().build(config));

If this was not intended - then we could remove the bridged config param in PolicyInit.initFromDeclarativeConfig(config, bridgedConfig) - is that correct?

[jackshirazi]

I believe so, but if you say that in case 3 (no declarative config but configprovider used), if the configprovider doesn't go through the declarative config component provider, what is the path that it uses to construct the agent?

[zeitlinger]

I believe so, but if you say that in case 3 (no declarative config but configprovider used), if the configprovider doesn't go through the declarative config component provider, what is the path that it uses to construct the agent?

• declarative config is active -> TelemetryPolicyDeclarativeCustomizerProvider and TelemetryPolicySamplerComponentProvider are used
• else -> DynamicControlAutoConfiguration is used

does that answer your question?

[zeitlinger]

@jackshirazi OK - I think I get where you're headed - and created #3013 to be ready for the 3.0 instrumentation release