You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Honeycomb opentelemetry-collector chart was created before a community opentelemetry-collector chart existed and filled the important need to easily deploy a collector that could export data to Honeycomb.
Today there is an OpenTelemetry Community Collector helm chart that is actively maintained and supports more features than our chart. In addition, exporting data to Honeycomb via the OpenTelemetry Collector has been simplified to the OTLP exporter with a small amount of configuration. At this time the only "advantage" our chart has is the ability to configure the OTLP exporter based on the user-supplied API key and dataset name. But the advantage comes at the cost of lack of useful k8s features, automatic complex component support (see the community chart's preset concept for more details`), and regular updates.
I propose we deprecate our opentelemetry-collector chart in favor of the community opentelemetry-collector chart, supplementing the Honeycomb-specific configuration that our chart provided with Honeycomb documentation. Instead of investing our time in our own chart, we invest our time helping maintain the OpenTelemetry community chart.
The text was updated successfully, but these errors were encountered:
## Which problem is this PR solving?
- Related to #231
## Short description of the changes
- Updates the collector chart's readme with a Sunset notice.
---------
Co-authored-by: Phillip Carter <[email protected]>
## Which problem is this PR solving?
- works towards #231
## Short description of the changes
- updates chart.yaml to deprecate the chart
- update readme to explicitly list deprecation
- update NOTES.txt to warn about deprecation
The Honeycomb opentelemetry-collector chart was created before a community opentelemetry-collector chart existed and filled the important need to easily deploy a collector that could export data to Honeycomb.
Today there is an OpenTelemetry Community Collector helm chart that is actively maintained and supports more features than our chart. In addition, exporting data to Honeycomb via the OpenTelemetry Collector has been simplified to the OTLP exporter with a small amount of configuration. At this time the only "advantage" our chart has is the ability to configure the OTLP exporter based on the user-supplied API key and dataset name. But the advantage comes at the cost of lack of useful k8s features, automatic complex component support (see the community chart's
preset
concept for more details`), and regular updates.I propose we deprecate our opentelemetry-collector chart in favor of the community opentelemetry-collector chart, supplementing the Honeycomb-specific configuration that our chart provided with Honeycomb documentation. Instead of investing our time in our own chart, we invest our time helping maintain the OpenTelemetry community chart.
The text was updated successfully, but these errors were encountered: