<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
The GetFactory method is used by a few receivers in the contrib package
(e.g. receiver_creator). This PR adds a new interface to the
hostcapabilities package so it can be cast correctly from other
packages/components.
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes #
<!--Describe what testing was performed and which tests were added.-->
#### Testing
<!--Describe the documentation added.-->
#### Documentation
<!--Please delete paragraphs that you did not use before submitting.-->
---------
Co-authored-by: Jade Guiton <jade.guiton@datadoghq.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
create `service/hostcapabilities` package to expose `GetModuleInfos()`
from service/host. Also moves getExporters interface for
`GetExporters()` to this package.
<!-- Issue number if applicable -->
#### Link to tracking issue
Addresses planned work from #12296
<!--Describe what testing was performed and which tests were added.-->
#### Testing
none, creates interface for existing function
<!--Describe the documentation added.-->
#### Documentation
changelog yaml
<!--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 -->
Moves `extension.Settings.ModuleInfo` to a `service.Host.GetModuleInfo`
method.
This field probably fits better on `extension.Settings` or even in
`component.BuildInfo`, but since its contents are a bit in flux per
discussions like #12283, I would like to move it here to not stabilize
it alongside the rest of `extension`.
The field is not used in any public code on Github, so I think it won't
have a huge impact to remove it in one go, happy to do this in two steps
if preferred.
One relevant difference is that this information is no longer available
at extension build time, but rather after the `Start` method is called.
Another relevant difference is that this is now available for all
component kinds, not just extensions. This could be worked around (we
could pass a different host depending on the component kind) but I don't
see the use right now.
#### Link to tracking issue
Updates #12283
#### 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>
#### Description
As part of
https://github.com/open-telemetry/opentelemetry-collector/pull/11204 I
left `host`'s implementation of `GetExporters` alone, thinking I didn't
need to change a deprecated interface implementation.
But `GetExporters` depends on `component.DataType`, so we won't be able
to remove `component.DataType` unless `GetExporters` is updated to use
`pipeline.Signal` instead.
This PR deprecates the deprecated `GetExporters` interface with
`GetExportersWithSignal`, which uses `pipeline.Signal`. Then we'll
follow the process to rename `GetExportersWithSignal` back to
`GetExporters`.
<!--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.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the processor builder out of the `processor` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the exporter builder out of the `exporter` package, and into
`service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the connector builder out of the `connector` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
While this is not technically required for the profiles work (there is
no notion of signals in extensions), this PR is here to keep things
consistent.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the connector builder out of the `connector` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
#### Description
This moves the receiver builder out of the `receiver` package, and into
`service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
#### Description
Paired with @djaglowski on adding a new struct, `ModuleInfo`, to
`extension.Settings`. The goal is to make the collector's component go
modules available to extensions that may want to use that information
(in particular the OpAMP extension).
We didn't want to modify the `extension` package but adding this
information to the Settings struct seems to be the most painless way to
make this information available. No function signatures need to be
updated and existing extensions can just ignore the new field on the
Settings struct unless they want the information.
#### Link to tracking issue
Fixes#10876
#### Testing
Updated existing tests.
---------
Co-authored-by: Dan Jaglowski <jaglows3@gmail.com>
#### Description
This PR removes `ReportStatus` from `component.TelemetrySettings` and
instead expects components to check if their `component.Host` implements
a new `componentstatus.Reporter` interface.
<!-- Issue number if applicable -->
#### Link to tracking issue
Related to
https://github.com/open-telemetry/opentelemetry-collector/pull/10725
Related to
https://github.com/open-telemetry/opentelemetry-collector/pull/10413
<!--Describe what testing was performed and which tests were added.-->
#### Testing
unit tests and a sharedinstance e2e test.
The contrib tests will fail because this is a breaking change. If we
merge this I and @mwear can commit to updating contrib before the next
release.
---------
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
Roger Coll
John L. Peterson (Jack)
Pablo Baeyens
Bogdan Drutu
Matthieu MOREL
Tyler Helmuth
Damien Mathieu
Dakota Paasman