#### Description
This updates replace gopkg.in/yaml.v3 with sigs.k8s.io/yaml
#### Link to tracking issue
Fixes#12827
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
There are a bunch of warnings in the lint output about tenv being
deprecated, and moving to usetesting. Reference:
https://golangci-lint.run/usage/linters/#tenv
#### Link to tracking issue
none
#### Testing
Ran `make golint` and `make all`
<!--Describe the documentation added.-->
---------
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
Koanf's default merging strategy currently overrides static values such
as slices, numbers, and strings. However, lists of components should be
treated as a special case. This pull request introduces a new command
line option to allow for merging lists instead of discarding the
existing ones.
With this new merging strategy:
- All the lists are merged rather than replaced.
- The merging logic is name-aware, meaning that if components with the
same name appear in both lists, they will only appear once in the final
merged list.
<!-- Issue number if applicable -->
#### Link to tracking issue
Related issues:
- https://github.com/open-telemetry/opentelemetry-collector/issues/8754
- https://github.com/open-telemetry/opentelemetry-collector/issues/8394
- https://github.com/open-telemetry/opentelemetry-collector/issues/10370
<!--Describe what testing was performed and which tests were added.-->
#### Testing
- Added
<!--Describe the documentation added.-->
#### Documentation
- Added under readme.
##### Example
Consider the following configs,
```yaml
# main.yaml
receivers:
otlp/in:
processors:
batch:
exporters:
otlp/out:
extensions:
file_storage:
service:
pipelines:
traces:
receivers: [ otlp/in ]
processors: [ batch ]
exporters: [ otlp/out ]
extensions: [ file_storage ]
```
```yaml
# extra_extension.yaml
extensions:
healthcheckv2:
service:
extensions: [ healthcheckv2 ]
```
If you run the collector with following command,
```
otelcol --config=main.yaml --config=extra_extension.yaml --feature-gates=-confmap.enableMergeAppendOption
```
then the final configuration after config resolution will look like
following:
```yaml
# main.yaml
receivers:
otlp/in:
processors:
batch:
exporters:
otlp/out:
extensions:
file_storage:
healthcheckv2:
service:
pipelines:
traces:
receivers: [ otlp/in ]
processors: [ batch ]
exporters: [ otlp/out ]
extensions: [ file_storage, healthcheckv2 ]
```
For backward compatibly, the default behaviour is **not** to merge
lists. Users who want to explicitly merge lists can enable the command
line option.
Note: I’d appreciate your feedback on this 🙏
#### Description
[Thelper](https://golangci-lint.run/usage/linters/#thelper) detects
tests helpers which is not start with t.Helper() method.
This only enables rules for naming and paramter order
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
#### Description
[gofumpt](https://golangci-lint.run/usage/linters/#gofumpt) is a
stricter format than gofmt, while being backwards compatible.
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
#### Description
Testifylint doesn't support it yet.
This replaces `Contains(t, err.Error()` by `ErrorContains(t, err` and
`Equal(t, err.Error()` by `EqualError(t, err`
As they both check for nil error it becomes useless to check it yourself
without having defined a custom message
<!-- Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com> -->
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Validate providers schemes when building a Resolver.
I don't consider this a breaking change since the providers would be
useless if they don't follow this pattern.
#### Description
This PR adds support for expanding `${}` syntax when no schema is
provided by allowing Resolver to use a default provider.
In a followup PR I'll update otelcol with a feature gate that allow
switching between a default envProvider and the expandconverter.
#### Link to tracking issue
Related to
https://github.com/open-telemetry/opentelemetry-collector/issues/10161
Related to
https://github.com/open-telemetry/opentelemetry-collector/issues/7111
#### Testing
Added unit tests
#### Documentation
Added godoc strings
---------
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
These fields were deprecated in v0.99.0 and aren't used in any upstream
repositories.
These appear to still be used in downstream distributions. If we want to
lengthen the deprecation period for these fields, I'll open a PR to
instead set a timeline for their removal.
**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>
* [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>
* confmap: Add support for nested URIs
Addresses #7117.
This PR adds support for nesting URIs, e.g.
```
test: "${http://example.com/?os=${env:OS}}"
```
**Breaking change:**
In the case of an InvalidScheme, error `invalid uri: "g_c_s:VALUE"` will be thrown. Previously, no error was thrown (see [test case](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.74.0/confmap/resolver_test.go#L623-L625)).
Other than the above, there will be no breaking changes. Although the parser now provides the ability to understand why parsing a URI fails (e.g. missing opening `${`), no errors will be thrown to preserve the previous behaviour.
The old way to expand env vars (e.g. `${HOST}`) is not supported in nested URIs, as expanding the old way is done in a converter. This has been documented.
* add issue # to changelog
* address feedback
* address feedback
* address feedback
* Address feedback: change expandStringURI & preserve comment
* Address feedback: move recursion to findURI
* Address feedback: avoid duplicate calls to findURI
* Update confmap/expand.go
Co-authored-by: Bogdan Drutu <lazy@splunk.com>
* Address Feedback
* remove unused errURILimit
* update findURI documentation
* fix test
* Update confmap/expand.go
* Address feedback: remove named return values
---------
Co-authored-by: Bogdan Drutu <lazy@splunk.com>
The new mechanism that allows embedding and expanding configs from all the Providers, does not doing it without explicitly specify the URI scheme.
If support for backwards compatibility is needed, continue to use the `expandconverter`.
Signed-off-by: Bogdan <bogdandrutu@gmail.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>
It is ok to change NewRetrievedFromMap to NewRetrieved since it was just moved, not yet released. This is a step towards supporting providing any value type.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
The reason to do this is to allow alternative implementation of the service.ConfigProvider to re-use the resolver logic,
also to create an independent "confmap.Conf" resolver for other services/binaries to use.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Alex Boten
Matthieu MOREL
Antoine Toulme
Matthew Sainsbury
Vihas Makwana
Nathan Baulch
Pablo Baeyens
Tyler Helmuth
Evan Bradley
Alex Boten
Mackenzie
Kshitij Patil
Bogdan Drutu