<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This PR adds a guideline about how metrics'/attributes' addition should
take place in (some) coordination with the Semantic Conventions project.
This addition does not introduce a hard requirement for now but rather
suggests how such coordination with Semantic Conventions can be
achieved.
If this gets merged I plan to extend Contrib's guidelines as well (i.e.
84f1030339/CONTRIBUTING.md (adding-metrics-to-existing-receivers))
to link back to this guideline.
<!-- Issue number if applicable -->
#### Link to tracking issue
Part of
https://github.com/open-telemetry/opentelemetry-collector/issues/13076
/cc @open-telemetry/collector-contrib-approvers
@open-telemetry/collector-approvers
Note: It's still to be defined how Semantic Conventions will affect
components' stability as described at
https://github.com/open-telemetry/opentelemetry-collector/issues/11878,
however prior to the stability concern this PR suggests to update our
contribution guidelines to cover for this treating it as a "soft"
requirement already.
---------
Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
Also added a link to the workflow in the releases repo.
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@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
<!-- Issue number if applicable -->
This updates the stability requirements to require certain benchmarking,
testing and documentation to ensure scalability, resiliency and
performance expectations are documented at a minimum level.
To operationalize this, I will work on:
- Adding automated context propagation tests for components for which it
is easy to do so (connectors and processors)
- Adding a new section to the table with a link to the latest
benchmarking results.
#### Link to tracking issue
Fixes#11866Fixes#11868Fixes#11593
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This updates the bugfix guidelines to make them less strict. In
particular, after this change, we would start releasing bugfix releases
under the following cases:
1. Lack of consensus of SIG leads on whether to release a bugfix version
within one working day after a report has been made
2. Issues that have not been reported by multiple people, but that are
known to be used in production
This also:
- Explicitly lists difficulties with debugging and troubleshooting as
'severe enough'
- Explicitly states that the release manager is responsible for bugfix
releases
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Updates release guidelines to reflect #12837
---------
Co-authored-by: Chao Weng <19381524+sincejune@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
<!-- Issue number if applicable -->
Adds wording regarding testing requirements for stable components. The
intent is for the lifecycle tests to be handled via mdatagen.
This follows the work done on
open-telemetry/opentelemetry-collector-contrib/issues/39543, with which
now we have component coverage per component.
#### Link to tracking issue
Fixes#11867
<!--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 a CodeCov status badge unless explicitly disabled.
I have disabled this in core until we roll this out in contrib to show
the Go SIG and move codecovgen to build tools
#### Link to tracking issue
Updates open-telemetry/opentelemetry-collector-contrib/issues/39583
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This RFC will help us explore the use cases Optional types solve and
move us toward a resolution for whether to adopt these in our config.
Related to #10266
---------
Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Code ownership and maintenance of components continues to be an issue,
with varying levels of support across contrib. As we approach 1.0 and
the ability to mark components as stable, we want to make sure that
components that we deem as 'stable' have a healthy community around
them. We have three datapoints that we can leverage here: how many
codeowners a component has, how diverse these are in terms of employers
and how actively the codeowners have been responding to issues/PRs in
the recent past.
We need criteria that
1. Are reasonable predictors of the component health over the
short/medium term
2. Are not too onerous on the code owners
Some notes:
1. Some beta components do not meet the criteria listed on the PR. This
will be the case even after the transition for some components. This PR
makes no claim as to what should happen to these components stability
(so, de facto, they will stay as is).
2. The OTLP receiver and exporters do not meet this criteria today
because they don't have listed code owners. We can solve this either by
carving out an exception or by listing code owners.
3. We need automation and templates to enforce this.
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#11850
---------
Co-authored-by: Christos Markou <chrismarkou92@gmail.com>
A few weeks ago, I mentioned to the Collector leads about my intention
to resign as maintainer/approver. My current focus on building
OllyGarden isn't leaving much room to be an approver or maintainer.
The plan right now is to ramp up again as approver/maintainer in the
future once time allows.
Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Added the cspell to check spelling in .md, .yaml files.
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#9287
<!--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.-->
---------
Signed-off-by: Yuri Oliveira <yurimsa@gmail.com>
There was no mention of disabling the merge queue which is needed if we
need to merge a commit (instead of squashing it)
Signed-off-by: Alex Boten <223565+codeboten@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
This PR changes the release workflow to autofill the release notes from
`CHANGELOG.md` and `CHANGELOG-API.md` into the generated GH release.
It makes use od `awk` and `sed` to build the release notes step by step
from the changelog files.
The [default chloggen
template](c43cb0331c/chloggen/internal/chlog/summary.tmpl)
was added and a `<!--preview-version-->` tag was added to easily filter
out the changelog of just the latest version.
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#10191
<!--Describe what testing was performed and which tests were added.-->
#### Testing
Tested on my fork.
Release with autofilled changelog:
https://github.com/mowies/opentelemetry-collector/releases/tag/v0.121.0
Workflow that did it:
https://github.com/mowies/opentelemetry-collector/actions/runs/13899615357/job/38888008499
<!--Describe the documentation added.-->
#### Documentation
The release checklist was updated accordingly.
<!--Please delete paragraphs that you did not use before submitting.-->
---------
Signed-off-by: Moritz Wiesinger <moritz.wiesinger@dynatrace.com>
#### Description
Once
[contrib#38534](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/38534)
is merged, the manual changes that were necessary in step 1 of releasing
contrib should now be included in step 2 (the Prepare Release CI
workflow). This PR updates the release doc to remove step 1.
#### Link to tracking issue
Updates #12294
#### Description
A very minor whitespace issue was preventing the list from formatting
correctly on one .md doc page. This fixes that _very minor_ issue.
Co-authored-by: Alex Boten <223565+codeboten@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
Simplifies description of automated release steps. While there is some
value in having the description of the automated steps somewhere, I
think this runs the risk of getting outdated and us having to look at
the code directly, so I would rather just remove it from here and
improve the comments/code of the automation over time. See
open-telemetry/opentelemetry-collector-releases/pull/856 for one
improvement of this kind.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Updates #12533
#### Description
This PR:
- requires "level: normal" before outputting batch processor metrics (in
addition to one specific metric which was already restricted to "level:
detailed")
- clarifies wording in the telemetry level guidelines and documentation,
and adds said guidelines to the requirements for stable components.
Some rationale for these changes can be found in the tracking issue and
[this
comment](https://github.com/open-telemetry/opentelemetry-collector/issues/7890#issuecomment-2684652956).
#### Link to tracking issue
Resolves#7890
#### To be discussed
Should we add a feature gate for this, in case a user relies on "level:
basic" outputting batch processor metrics? This feels like a niche use
case, so considering the "alpha" stability level of these metrics, I
don't think it's really necessary.
Considering batch processor metrics had already been switched to
"normal" once (#9767), but were turned back to basic at some later point
(not sure when), we might also want to add tests to avoid further
regressions (especially as the handling of telemetry levels is bound to
change further with #11754).
---------
Co-authored-by: Dmitrii Anoshin <anoshindx@gmail.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Add guidelines for naming Go modules
Note the 3-week window between .128 and .129, as we'll likely have OTel
Community Day on the week of June 23. An alternative to that is to have
the release on June 23 and assign to someone who knows already that they
won't be there anyway.
Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
<!--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 -->
Reworks breaking changes section to include information about our
approach to feature gates.
---------
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
fix metadata.yaml github_project, add a go:generate instruction to
confmap and a banner to README
### This PR
- adds the githubgen tool as a dependency in internal/tools
- uses githubgen to generate codeowners and issue template files
- updates lots of metadata files by
- taking the existing codeowners file and feeding the info from there
back into the component metadata.yaml files or creating new
metadata.yaml files where none existed yet
- adds distributions.yaml as a basis the mostly already existing
`distributions:` keys in metadata.yaml files (needed for githubgen to
work correctly)
- adds relevant make commands to make the githubgen tool usage mostly
transparent to users
This change is a prerequisite to be able to ping codeowners reliably
with automated tooling as a next step.
Part of #11562
---------
Signed-off-by: Moritz Wiesinger <moritz.wiesinger@dynatrace.com>
<!--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 -->
Use h2 (hN-1) titles for h2 (hN-1) sections instead of h3 (hN)
### Context
The [Pipeline Component Telemetry
RFC](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/rfcs/component-universal-telemetry.md)
was recently accepted (#11406). The document states the following
regarding error monitoring:
> For both [consumed and produced] metrics, an `outcome` attribute with
possible values `success` and `failure` should be automatically
recorded, corresponding to whether or not the corresponding function
call returned an error. Specifically, consumed measurements will be
recorded with `outcome` as `failure` when a call from the previous
component the `ConsumeX` function returns an error, and `success`
otherwise. Likewise, produced measurements will be recorded with
`outcome` as `failure` when a call to the next consumer's `ConsumeX`
function returns an error, and `success` otherwise.
[Observability requirements for stable pipeline
components](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md#observability-requirements)
were also recently merged (#11772). The document states the following
regarding error monitoring:
> The goal is to be able to easily pinpoint the source of data loss in
the Collector pipeline, so this should either:
> - only include errors internal to the component, or;
> - allow distinguishing said errors from ones originating in an
external service, or propagated from downstream Collector components.
Because errors are typically propagated across `ConsumeX` calls in a
pipeline (except for components with an internal queue like
`processor/batch`), the error observability mechanism proposed by the
RFC implies that Pipeline Telemetry will record failures for every
component interface upstream of the component that actually emitted the
error, which does not match the goals set out in the observability
requirements, and makes it much harder to tell which component errors
are coming from from the emitted telemetry.
### Description
This PR amends the Pipeline Component Telemetry RFC with the following:
- restrict the `outcome=failure` value to cases where the error comes
from the very next component (the component on which `ConsumeX` was
called);
- add a third possible value for the `outcome` attribute: `rejected`,
for cases where an error observed at an interface comes from further
downstream (the component did not "fail", but its output was
"rejected");
- propose a mechanism to determine which of the two values should be
used.
The current proposal for the mechanism is for the pipeline
instrumentation layer to wrap errors in an unexported `downstream`
struct, which upstream layers could check for with `errors.As` to check
whether the error has already been "attributed" to a component. This is
the same mechanism currently used for tracking permanent vs. retryable
errors. Please check the diff for details.
### Possible alternatives
There are a few alternatives to this amendment, which were discussed as
part of the observability requirements PR:
- loosen the observability requirements for stable components to not
require distinguishing internal errors from downstream ones → makes it
harder to identify the source of an error;
- modify the way we use the `Consumer` API to no longer propagate errors
upstream → prevents proper propagation of backpressure through the
pipeline (although this is likely already a problem with the `batch`
prcessor);
- let component authors make their own custom telemetry to solve the
problem → higher barrier to entry, especially for people wanting to
opensource existing components.
---------
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
<!--Describe the documentation added.-->
#### Documentation
This is a documentation-only change to fix some typos in the Pipeline
Component Telemetry RFC doc.
<!--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 -->
Proposal for creating a new `collector-release-approvers` group.
Announced at:
- #otel-collector-dev on 2024-10-30:
https://cloud-native.slack.com/archives/C07CCCMRXBK/p1730307025302339
- Collector SIG on 2024-11-05 (TBD)
The stakeholders for this PR are:
- @open-telemetry/collector-approvers
- @open-telemetry/collector-contrib-approvers
---------
Co-authored-by: Andrzej Stencel <andrzej.stencel@elastic.co>
<!--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 requirements for documentation for different stability levels.
I expect many of these will be done through automation over time :)
#### Link to tracking issue
Fixes#11852
#### Description
This PR slightly changes the wording of the "Stability levels and
versioning" doc (`docs/component-stability.md`), which I found a bit
confusing, in order to:
- Emphasize the important fact that stability levels for a component are
defined _per signal_. At the moment this is only alluded to at the
beginning and assumed in the last section. Moreover, things like the
"Unmaintained" level may give the impression that stability levels
always apply to an entire component.
- More cleanly separate the part about behavior changes from the part
about API changes in the "Versioning" section.
This should not change the content or interpretation of the document.
Roger Coll
Christos Markou
Alex Boten
John L. Peterson (Jack)
Juliano Costa
Dmitry Anoshin
Pablo Baeyens
Daniel Jaglowski
Yang Song
Evan Bradley
Joshua MacDonald
Antoine Toulme
Bogdan Drutu
Juraci Paixão Kröhling
Tyler Helmuth
Moritz Wiesinger
Yuri Sa
Jade Guiton
Benjamin Blattberg
Guspan Tanadi
Curtis Robert