#### 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>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Allows any type to be used as a string if the target field is a string
or the value is expanded in inline position. Inspired by #10794. This is
not a breaking change (previously we would return an error for these).
Some things that you can do after this PR that you couldn't do before
it:
1. Set `HOST` to `[2001:db8::8a2e:370:7334]` and use it in an endpoint:
```yaml
exporters:
otlp:
endpoint: http://${env:HOST}/api/v1/traces
```
2. Pass really big numbers as strings (e.g. `10000000000000000000`)
3. Pass `null` as a string.
<details>
<summary>Types that can be returned by our current YAML parser</summary>
Our current way of using the YAML parser has these types: `string`,
`nil`, `int`, `uint64`, `float64`, `map[any]any`, `map[string]any`,
`[]any`.
There is no documentation for this, but the following fuzzing test did
not find any failing cases after 20 minutes of continous run:
```go
package main
import (
"testing"
"gopkg.in/yaml.v3"
)
func FuzzTest(f *testing.F) {
f.Fuzz(func(t *testing.T, data []byte){
var b any
err := yaml.Unmarshal([]byte(data), &b)
if err != nil {
return
}
switch b.(type) {
case string, nil, int, uint64, float64, map[any]any, map[string]any, []any:
return
default:
t.Errorf("Unexpected type %T", b)
}
})
}
```
</details>
<!--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.
This change fixes the issue where environment variables escaped with $$
are expanded. The collector now converts `$${ENV_VAR}` to `${ENV_VAR}`
and `$$ENV_VAR` to `$ENV_VAR` without further expansion (or the
expansion failure in case of `$ENV_VAR`).
Fixes
https://github.com/open-telemetry/opentelemetry-collector/issues/10713
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Makes type resolution strict and conforming to the behavior described in
[the env vars
RFC](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/rfcs/env-vars.md)
Depends on:
- #10553
- #10555
- #10559
- open-telemetry/opentelemetry-collector-contrib/pull/33950
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#9532, Fixes#8565
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
When we promoted `confmap.unifyEnvVarExpansion` to beta, we found that
the new expansion logic in `confmap` wasn't handling escaping of `$$`
like it is supposed to. This PR fixes that bug, but adding escaping
logic for `$$`.
@azunna1 this fixes the bug you mentioned in
https://github.com/open-telemetry/opentelemetry-collector/pull/10435
around the metricstransformprocessor:
```yaml
metricstransform:
transforms:
- include: '^k8s\.(.*)\.(.*)$$'
match_type: regexp
action: update
new_name: 'kubernetes.$${1}.$${2}'
- include: '^container_([0-9A-Za-z]+)_([0-9A-Za-z]+)_.*'
match_type: regexp
action: update
new_name: 'container.$${1}.$${2}'
```
#### Testing
Added new unit tests explicitly for escaping logic
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Adds string representation to all inputs returned by mock env provider
used in tests.
The real `env` provider (and all other providers on this repository) do
this by default since they use `NewRetrievedFromYAML`.
Note that certain types are not really obtainable with the real `env`
provider (e.g. `int32` or `float64`). I have kept them and added the
string representation manually.
#### Link to tracking issue
Needed for #10554
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### 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>
**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>