<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Add `component.Type` parameter to `NewNopSettings` And deprecate
`NewNopSettingsWithType` cc @mx-psi
<!-- Issue number if applicable -->
#### Link to tracking issue
Relevant to #12305
<!--Describe what testing was performed and which tests were added.-->
#### Testing
Updated
<!--Describe the documentation added.-->
#### Documentation
Added
<!--Please delete paragraphs that you did not use before submitting.-->
<!--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 -->
Creates `NewNopSettingsWithType` function on test modules and deprecates
the `NewNopSettings` functions on those modules. Replace all usages of
`NewNopSettings` with `NewNopSettingsWithType`.
Part of #12305 but applied to all component kinds.
#### Link to tracking issue
Updates #12221
This PR just cleans up some naming in the `testcomponents` package, so
that no component kind has a monopoly on the generic version of a
variable or function name.
Subset of #12057
#### 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>
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This change makes the names to be more "Go" friendly. Also it will not
become an issue that types will try to implement different Factory types
(receiver,processor) because that is forbidden because of our design.
This also makes the names consistent with connector.Factory.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This is the last PR to add profiles support, adding it to the service
package.
This is based after #11023.
This deprecates CreateSettings in favour of Settings.
NewNopCreateSettings is also being deprecated in favour of
NewNopSettings
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This deprecates CreateSettings in favour of Settings.
NewNopCreateSettings is also being deprecated in favour of
NewNopSettings
Part of #9428
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This deprecates CreateSettings in favour of Settings.
NewNopCreateSettings is also being deprecated in favour of
NewNopSettings
Part of #9428
~Follows
https://github.com/open-telemetry/opentelemetry-collector/pull/10333~
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This deprecates CreateSettings in favour of Settings.
NewNopCreateSettings is also being deprecated in favour of
NewNopSettings
Part of #9428
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This reduces dependencies from the consumer package while making
testdata available across repos. It will allow us to remove duplicated
code and its a fairly small surface area.
Fixes
https://github.com/open-telemetry/opentelemetry-collector/issues/9886
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
**Description:**
- Adds `component.MustNewType` to create a type. This function panics if
the type has invalid characters. Add similar functions
`component.MustNewID` and `component.MustNewIDWithName`.
- Adds `component.Type.String` to recover the string
- Use `component.MustNewType`, `component.MustNewID`,
`component.MustNewIDWithName` and `component.Type.String` everywhere in
this codebase. To do this I changed `component.Type` into an opaque
struct and checked for compile-time errors.
Some notes:
1. All components currently on core and contrib follow this rule. This
is still breaking for other components.
2. A future PR will change this into a struct, to actually validate this
(right now you can just do `component.Type("anything")` to bypass
validation). I want to do this in two steps to avoid breaking contrib
tests: we first introduce this function, and after that we change into a
struct.
**Link to tracking Issue:** Updates #9208
**Description:**
It was suggested that we add the [goleak
package](https://pkg.go.dev/go.uber.org/goleak) to every test in core.
This change adds `goleak` to every package that is succeeds with goleak.
There a number that are not successful, the full list of which I've
posted in the bug.
I generated these files using a shell script to copy a template
`main_test.go` file into each package, then modified the package name.
I'm sure there was a better way to automate this, but it worked well
enough at this point. Here's the script:
```
cp ./main_test.go $1
PACKAGE_NAME=$(basename $1)
sed -i '' -e "s|package component|package $PACKAGE_NAME|g"
$1/main_test.go
pushd . && cd $1 && go mod tidy
go test -v .
```
Usage example:
```
$ ./add_leak_test reciever/scrapererror
```
**Link to tracking Issue:**
#9165
**Testing:**
All added tests are passing, but there are a number failing. Note that there's no sign of `goleak` running until it fails.
This fixes two closely related problems.
1. While fanoutconsumers do not themselves mutate data, they should
expose whether or not they are handing data off to consumers which may
do so. Otherwise, the service cannot correctly determine how to fan out
after a receiver. e.g. a receiver shared between two pipelines, one of
which contains an exporter or connector which mutates data.
2. Connectors can themselves mutate data but we were not taking this
into account when building the graph.
Alternate to
https://github.com/open-telemetry/opentelemetry-collector/pull/8003
Fixes
#https://github.com/open-telemetry/opentelemetry-collector/issues/7892
Validation of connectors was too aggressive such that a connector that
was used in any combination of unsupported roles would fail. Instead,
validation should pass as long as each use of the connector has a
supported corresponding use.
For example, the forward connector may forward traces and metrics at the
same time. Previously, validation would fail because it detected that
traces->metrics and metrics->traces were possible connections. Now it
will pass as long as there is a supported connection type for each
pipeline in which the connector is used.
This PR adds helpers to `connectortest` to aid the construction of
`connector.*Router`s for testing connectors. This was implemented based
on @djaglowski's [comment
here](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/21498#issuecomment-1542682841),
with some slight modifications. I found it more ergonomic to pass the
sink into the `WithTracesSink` (and similar) options. You usually want a
handle on the sink after creating the router. While it's possible to get
the sink out of the router after the fact, it's a little cumbersome.
These helpers will be useful for
https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/21498
and future connectors that need use of routers.
For example, here is a test with the consumer passed in:
```go
func TestFanoutTracesWithSink(t *testing.T) {
var sink0, sink1 consumertest.TracesSink
tr, err := NewTracesRouterSink(
WithTracesSink(component.NewIDWithName(component.DataTypeTraces, "0"), &sink0),
WithTracesSink(component.NewIDWithName(component.DataTypeTraces, "1"), &sink1),
)
require.NoError(t, err)
require.Equal(t, 0, sink0.SpanCount())
require.Equal(t, 0, sink1.SpanCount())
td := testdata.GenerateTraces(1)
err = tr.(consumer.Traces).ConsumeTraces(context.Background(), td)
require.NoError(t, err)
require.Equal(t, 1, sink0.SpanCount())
require.Equal(t, 1, sink1.SpanCount())
}
```
The same test having to extract the consumer out after the fact:
```go
func TestFanoutTracesWithSink(t *testing.T) {
traces0 := component.NewIDWithName(component.DataTypeTraces, "0")
traces1 := component.NewIDWithName(component.DataTypeTraces, "1")
tr, err := NewTracesRouterSink(
WithTracesSink(traces0),
WithTracesSink(traces1),
)
require.NoError(t, err)
cons0, _ := tr.Consumer(traces0)
sink0 := cons0.(*consumertest.TracesSink)
cons1, _ := tr.Consumer(traces1)
sink1 := cons1.(*consumertest.TracesSink)
require.Equal(t, 0, sink0.SpanCount())
require.Equal(t, 0, sink1.SpanCount())
td := testdata.GenerateTraces(1)
err = tr.(consumer.Traces).ConsumeTraces(context.Background(), td)
require.NoError(t, err)
require.Equal(t, 1, sink0.SpanCount())
require.Equal(t, 1, sink1.SpanCount())}
}
```
**Link to tracking Issue:**
#7672
**Testing:**
Unit tests
**Documentation:**
Source code comments
---------
Co-authored-by: Daniel Jaglowski <jaglows3@gmail.com>
Resolves#7776
The collector copies data whenever handing it to components that may mutate it. The point at which a copy must be made is within a fanout consumer. There are two points at which a fanout consumer may be placed:
1. Immediately after a receiver shared by multiple pipelines
2. Immediately before multiple exporters of a single pipeline
When data is fanned out _to_ a connector (acting as an exporter), we must ensure that the fanout consumer before exporters (point 2 above) is able to take into account whether or not the connector will be handing the data off to a pipeline that will mutate the data.
* [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>
The main reason is to remove the circular dependency between the config (including sub-packages) and component. Here is the current state:
* component depends on config
* config/sub-package[grpc, http, etc.] depends on config & component
Because of this "circular" dependency, we cannot split for example "config" into its own module, only if all the other config sub-packages are also split.
Signed-off-by: Bogdan <bogdandrutu@gmail.com>