Use config file for the SDK configuration

[maryliag]

Follow guidelines from here to use a yaml file with configurations for the SDK

[pichlermarc]

A brain dump of ideas that I had no time to write down yet on how we could go about this 🙂

• strip out any env var config from SDK packages
  • @opentelemetry/sdk-metrics is already done
  • @opentelemetry/sdk-trace-base is still reading some of these
    • we'd have to refactor it in a way so that we have "clean" classes that don't read env vars at all, but public facing we still export all the types that do read env vars
    • split the new "clean" classes out into a new package @opentelmetry/sdk-trace which does not implement any env var reading at all
    • this becomes the new default trace package, we can then deprecate and subsequently remove @opentelemetry/sdk-trace-base, @opentelemetry/sdk-trace-node and @opentelemetry/sdk-trace-web in 3.0, and we roll any functionality that's lost into@opentelemetry/sdk-node
  • @opentelemetry/sdk-logs we also have to strip any env var config but we can break users since it's still an experimental package, any env var capability that gets lost we can roll into @opentelemetry/sdk-node
  • the exporters will need a similar interface so that we can instantiate them without any env var config being applied, I already did a lot of work towards this in feat(exporters)!: rewrite exporter config logic #4971, we should do the rest as part of [exporters] OTLP Exporter stabilization plan #4585
• introduce a new, cleaner way to use @opentelemetry/sdk-node, where users can select to use either env var config or file config.
  • ideally we re-build this from the ground-up, with a sort of pluggable config-provider structure that allows us to re-use code across env var and file config (or a component that generates a config file from env vars, and uses that for setup - that would force us not to diverge in feature-set between file and env var config)

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[maryliag]

My idea is to start with the second bullet point, choosing one package in the main repo to use as a proof of concept, then eventually move to other packages. My plan is:

• Create a ConfigProvider in the opentelemetry-core package
• At the first version the ConfigProvider only use env var, so it won't change the existing behaviour
• I will manually create a class Configuration, which will have all parameters defined in the config spec. The idea is to eventually have this automated, similar to sem conv, so we are always aligned
• Now when ConfigProvider is initialized, it checks all the values from env var or default when those are not set, and create an object for config, which can then be read by any other package
• Pick another package as the test (open to suggestions here) and replace all the calls for getEnv* to call the new ConfigProvider that will return those values
• After this is all working with env var, add functionality to construct this config object from a config file and return that on the ConfigProvider (still giving the option to use env var when file doesn't exist)
• When this is working for this test package, then move on to others, including the removal of reading env var at all when it make sense, as suggested on prior comment by Marc

[JamieDanielson]

This sounds great. We are considering this having its own package instead of being inside of opentelemetry-core. This allows for experimentation with the implementation. We've also been considering deprecating the opentelemetry-core package so it seems best to avoid adding anything new there.

[maryliag]

Closing this issue, since the work has been broken down into other issues
Declarative Configuration: JavaScript (view)