Loosen requirements for component-specific config

[pellared]

Hmm, I don't really want to change the existing ones, plus as an end user when you're configuring a JS service, I don't think the JS part adds much

OK. I also see that Java also does more or less the same: https://github.com/signalfx/splunk-otel-java/blob/main/docs/advanced-config.md. I think we should loosen the requirement below:

If a new configuration variable is needed by a GDI repository it MUST be brought to the GDI specification as a GitHub issue.

Originally posted by @pellared in signalfx/splunk-otel-js#978 (comment)

[MrAlias]

I think without some reference back here we will have a source of divergence/conflict. A language will add a feature, it will be adopted, customers will ask for it in other languages, other languages will determine it is not possible or needs to be changed, and this will result in language implementation divergence or direct conflict that results in breaking changes being introduced to already released functionality.

Ideally, we get ahead of these things. I think bringing them to the group via this repository is an ideal approach, but we should search for alternative if we plan to change that.

[pellared]

The issue is mostly about loosening it only for instrumentation library-specific configs. E.g. there is currently an SPLUNK_NEXTJS_FIX_ENABLED env var in splunk-otel-js.

My initial proposal was to have a different pattern for them: SPLUNK_{LANGUAGE}_{FEAUTRE}, e.g. SPLUNK_JS_NEXTJS_FIX_ENABLED. The proposal is based on https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#language-specific-environment-variables.

Thoughts?

[MrAlias]

I think language specific environment variables make sense.

They will need to be carefully specified so they don't just become a catch all to circumvent the GDI spec process though.

[pellared]

Found some pre-work:

• Add a SPLUNK_{COMPONENT}_ prefix recommendation #234
• Handling distribution-specific configuration #198

By @pjanotti

The key is to have a discussion about why some env var is needed in some instrumentation: even if it becomes "stable" but makes only sense for one language/runtime I don't think we should bring it to the GDI spec.

Which is about:

If a new configuration variable is needed by a GDI repository it MUST be brought to the GDI specification as a GitHub issue.

So far we had none repo specific variable requests so the GDI maintainers were not even considering how to tackle such things. @signalfx/gdi-js-maintainers, I think that only our Node.js distro has many SPLUNK_ env vars which are not defined in the GDI spec. The only other repo I found that uses an env var not defined in the GDI spec is Java but this is only a single SPLUNK_METRICS_FORCE_FULL_COMMANDLINE experimental env var. CC @signalfx/gdi-java-maintainers

[seemk]

I don't think everything needs to be documented in the GDI spec. Node.js has a few env vars that have been added for customers, e.g. SPLUNK_NEXTJS_FIX_ENABLED, which may be removed or turned into a no-op in the future once Next.js has their issues fixed.

If a new configuration variable is needed by a GDI repository it MUST be brought to the GDI specification as a GitHub issue. - I don't think this rule makes much sense, way too much bureaucracy to get anything released quickly.

What would adding language specific prefixes add exactly? E.g. SPLUNK_JS_NEXTJS_FIX_ENABLED vs SPLUNK_NEXTJS_FIX_ENABLED.

[pellared]

If a new configuration variable is needed by a GDI repository it MUST be brought to the GDI specification as a GitHub issue.

I don't think this rule makes much sense, way too much bureaucracy to get anything released quickly.

1. I do not think creating an issue takes long.
2. We should not rush with introducing new configuration that later customers may expect us to support.
3. Prioritize fixing in upstream.

What would adding language specific prefixes add exactly? E.g. SPLUNK_JS_NEXTJS_FIX_ENABLED vs SPLUNK_NEXTJS_FIX_ENABLED.

Predictable pattern. E.g. I would prefer having SPLUNK_JS_REDIS_INCLUDE_COMMAND_ARGS than SPLUNK_REDIS_INCLUDE_COMMAND_ARGS to indicate that it JS instrumentation library specific.

[seemk]

What is the actual problem we are solving with this?

[pellared]

What is the actual problem we are solving with this?

Consistency, feature-parity, avoiding feature creeping.

Assigning @akubik-splunk who will help solving this issue.