<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Use mdatagen for the file provider. This switches the package test to be
generated and adds an autogenerated section to the readme.
I've also populated the readme with basic usage information.
#### Description
<!-- Issue number if applicable -->
- Add `confmap.strictlyTypedInput` feature gate that introduces stricter
type checks when resolving configuration
- Make `confmap.NewRetrievedFromYAML` function public so that external
providers have consistent behavior when resolving YAML
- Adds `confmap.Retrieved.AsString` method to retrieve string
representation for retrieved values
#### Link to tracking issue
Relates to #9854, updates #8565, #9532
#### Description
Each of these was deprecated in v0.99.0, so I think removing them in
v0.101.0 is a safe deprecation period for an API that is likely only
used by vendor distros built without ocb.
If we would like to extend the deprecation period or break this change
into PRs for each module, let me know and I'll make the necessary
changes.
**Description:**
Follows
https://github.com/open-telemetry/opentelemetry-collector/pull/9443,
relates to
https://github.com/open-telemetry/opentelemetry-collector/pull/9513.
This builds on
https://github.com/open-telemetry/opentelemetry-collector/pull/9228 to
demonstrate the concept.
This shows one way of extending the otelcol APIs to allow passing
converters and providers from the builder with the new settings structs
for each type.
I think this approach has a few advantages:
1. This follows our pattern of passing in "factory" functions instead of
instances to the object that actually uses the instances.
2. Makes the API more declarative: the settings specify which modules to
instantiate and which settings to instantiate them with, but don't
require the caller to actually do this.
3. Compared to the current state, this allows us to update the config at
different layers. A distribution's `main.go` file can specify the
providers/converters it wants and leave the settings to be created by
`otelcol.Collector`.
The primary drawbacks I see here are:
1. This is a little more opinionated since you don't have access to the
converter/provider instances or control how they are instantiated. I
think this is acceptable and provides good encapsulation.
2. The scheme->provider map can now only be specified by the providers'
schemes, which is how it is currently done by default. I would want to
hear what use cases we see for more complex control here that
necessitates using schemes not specified by the providers.
cc @mx-psi
---------
Co-authored-by: Evan Bradley <evan-bradley@users.noreply.github.com>
**Description:**
For both #5615 and #9162 we need to be able to log during the confmap
resolution.
My proposed solution is to pass a `*zap.Logger` to converters and
providers during initialization. These components can then use this to
log any warnings they need. This PR does the first step: being able to
pass anything to converters and providers during initialization.
The obvious alternative to this is to change the interface of
`confmap.Provider` and `confmap.Converter` to pass any warnings in an
explicit struct. I think the `*zap.Logger` alternative is more natural
for developers of providers and converters: you just use a logger like
everywhere else in the Collector.
One problem for the Collector usage of `confmap` is: How does one pass a
`*zap.Logger` before knowing how a `*zap.Logger` should be configured? I
think we can work around this by:
1. Passing a special 'deferred' Logger that just stores the warnings
without actually logging them (we can use something like
`zaptest/observer` for this)
2. Resolving configuration
3. Building a `*zap.Logger` with said configuration
4. Logging the entries stored in (1) with the logger from (3) (using
`zaptest/observer` we can do that by taking the `zapcore.Core` out of
the logger and manually writing)
**We don't actually need ProviderSettings today, just ConverterSettings,
but I think it can still be useful.**
**Link to tracking Issue:** Relates to #5615 and #9162
---------
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
* [chore] use license shortform
To remain consistent w/ contrib repo, see https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/22052
Signed-off-by: Alex Boten <aboten@lightstep.com>
* make goporto
Signed-off-by: Alex Boten <aboten@lightstep.com>
---------
Signed-off-by: Alex Boten <aboten@lightstep.com>
This change makes implementations cleaner, since they can return `nil, err` in case of an error instead of a zero initialized Retrieved.
This is a breaking change, but there are very very few implementation of the Provider, so it should be safe to just break it.
Signed-off-by: Bogdan <bogdandrutu@gmail.com>
Adding the latest version of go to the tests run by CI. To pass the tests, the following changes were required:
- run make genpdata
- fix test certificates to address errors caused by the rejection of duplicate extensions in TLS handshakes