Configurator improvements

[mwear]

The configurator was introduced to simplify SDK setup, which used to be fairly cumbersome. It was a step in the right direction, but could use some attention and improvements before GA. This issue is to discuss and track desired changes.

[mwear]

Currently a user has to do the following to set up custom propagation (B3 in this case):

require 'opentelemetry-sdk'
require 'opentelemetry-propagator-b3'

OpenTelemetry::SDK.configure do |c|
  c.http_extractors = [OpenTelemetry::Propagator::B3::Single.rack_extractor, OpenTelemetry::Propagator::B3::Multi.rack_extractor]
  c.http_injectors = [OpenTelemetry::Propagator::B3::Single.rack_injector]
  c.text_map_extractors = [OpenTelemetry::Propagator::B3::Single.text_map_extractor, OpenTelemetry::Propagator::B3::Multi.text_map_extractor]
  c.text_map_injectors = [OpenTelemetry::Propagator::B3::Single.text_map_injector]
end

on gitter @genebean suggested having:

something like c.enable_b3 that does all the things

That specific approach might be challenging due to b3 being in a separate package, but we should be able to come up with something reasonable for supported propagation formats.

[mwlang]

I'm starting to think we may benefit from having a separate Config class that holds config state and is a Singleton Object (not singleton pattern). If we did something like this, other dependency gems that add additional functionality could reopen the Config class and add a method like enable_b3 to "do all the things". Configure would still do it's thing, but also set states on the Config class along the way so everything stays sync'd.

[mwear]

We should keep that option on the table, but for configuring propagation generally, I think it'd be sufficient to have a propagators option that takes a comma delimited string of well known propagator names. For example,c.propagators = 'tracecontext,baggage'. This would match the behavior needed for the OPENTELEMETRY_PROPAGATORS environment variable as well.

We can build this on top of the individual *_injectors and *_extractors accessors and leave them as is for more sophisticated scenarios.

[mwear]

@mwlang what do you think about this as an approach for #412? If the b3 gem is present we could expose three b3 configurations: b3, b3multi, and b3single. b3 would setup extractors for b3 single and b3 multi, but only one injector for b3 single. This is due to the spec requirements listed here: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md#b3-requirements. b3single and b3multi would wire up only one set of injectors and extractors (either the single or multi variants).

[mwlang]

@mwear I missed this comment from days ago. I definitely agree with adding a propagators option and I will wire it up as you described for b3. Thanks for linking the b3-requirements section. One thing I wanted to raise here before I got too far along, unless there's a strong desire to build a solution that's easily extensible, I am planning to centralize the logic for validating and wiring up propagators in one central place in the configurator.

Does that work?

[fhwang]

See also #321.

[mwear]

Closing as the SIG is happy with the configurator and improvements it has received since this was opened. Feel free to open issues for any future improvements that come up.