Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialize configuration factory #5687

Merged

Conversation

jack-berg
Copy link
Member

@jack-berg jack-berg commented Aug 7, 2023

This builds on #5399 by laying the groundwork for interpreting the parsed OpenTelemetryConfiguration model.

Some notes:

  • Interpreting a configuration model is very similar to what is already done in autoconfigure, except this reads properties from a strongly typed model instead of ConfigProperties. When this matures, there will be an opportunity to unify the code. For example, we may be able to convert the environment variable / system property scheme to an equivalent OpenTelemetryConfiguration model.
  • This initial PR covers interpreting the portions of the model related to SdkLoggerProvider. Will cover SdkMeterProvider, SdkTracerProvider, Propagators, Resource, and general AttributeLimits in future PRs.
  • This establishes a common pattern for interpreting a portion of the configuration model in the Factory interface, with contract ResultT create( @Nullable ModelT model, ServiceLoaderHelper serviceLoaderHelper, List<Closeable> closeables).
    • Accepts some portion of the configuration model, and is responsible for returning some configured type.
    • Can use ServiceLoaderHelper to load any SPIs if needed.
    • Responsible for populating List<Closeables> with any closeable components it builds, so allow for cleanup of partials if something goes wrong.
    • These factories can be arranged hierarchically, with the top of the hierarchy being OpenTelemetryConfigurationFactory, which resolves a complete OpenTelemetrySdk.
    • All of these factories are internal implementation details hidden from the user.
  • The public entrypoint of the API is ConfigurationFactory, which has an API public static OpenTelemetrySdk parseAndInterpret(InputStream inputStream), responsible for parsing an input stream of YAML configuration to a OpenTelemetryConfiguration model, and interpreting that model to create OpenTelemetrySdk.

@codecov
Copy link

codecov bot commented Aug 7, 2023

Codecov Report

Patch coverage has no change and project coverage change: +0.02% 🎉

Comparison is base (917d75d) 91.24% compared to head (f22cfc0) 91.26%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #5687      +/-   ##
============================================
+ Coverage     91.24%   91.26%   +0.02%     
  Complexity     5045     5045              
============================================
  Files           558      558              
  Lines         14924    14924              
  Branches       1397     1397              
============================================
+ Hits          13618    13621       +3     
+ Misses          899      897       -2     
+ Partials        407      406       -1     

see 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jack-berg jack-berg force-pushed the initialize-configuration-factory branch from 448c7d3 to 854b537 Compare August 9, 2023 20:17
cleanup.addCloseable(sdk);
cleanup.addCloseables(closeables);

assertThat(sdk.toString()).isEqualTo(expectedSdk.toString());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are pretty cool tests. We create a configuration model, parse / interpret it, and compare the toString() result to an expected version we build up manually. Its a bit strange to use toString as a stand in for equality, but I think it makes sense in this case because these aren't data carrier objects.

// opentelemetry-configuration
if (example.getName().equals("anchors.yaml")) {
continue;
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@trask an unexpected side affect of switching from snakeyaml to snakeyaml-engine is that the merge symbol isn't supported anymore, which reduces the ability to use anchors.

With merge, you can reference an anchor and extend it with additional elements:

my-anchor: &my-anchor
  foo: bar

my-object:
  <<: *my-anchor
  baz: qux

With anchor support, should result in:

my-object:
  foo: bar
  baz: qux

But instead results in:

my-object:
  <<: 
    foo: bar
  baz: qux

@jack-berg jack-berg marked this pull request as ready for review August 9, 2023 20:32
@jack-berg jack-berg requested a review from a team August 9, 2023 20:32
Copy link
Member

@tylerbenson tylerbenson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a great start to me.

@jack-berg
Copy link
Member Author

@open-telemetry/java-approvers take a look when you can. Want to get this merged so I can proceed with the trace / metric implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants