<!--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 -->
Amends universal telemetry RFC with proposed implementation for logs
(see #13474 for the implementation).
Notably, we don't log every outcome but instead only log errors. We can
start logging individual outcomes in the future but I feel like this
would not be useful in most cases
#### Link to tracking issue
Updates #13357
@evan-bradley please review as I have swapped you to run the release on
9/8.
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
I was puzzling over what "hss" meant when looking at confighttp earlier,
and realized it's a holdover from when the struct was named
`HTTPServerSettings`. This renames the receiver variables for both
`ClientConfig` and `ServerConfig` to be initialisms of these two types.
This updates the release schedule since 0.131.0 is out.
Not sure if the release right after Christmas is skipped or not :)
---------
Co-authored-by: Yang Song <songy23@users.noreply.github.com>
Non functional change, just updating more documentation to remove
references to the batch processor.
Signed-off-by: alex boten <223565+codeboten@users.noreply.github.com>
This updates some of the documentation to remove the reference to the
batch processor.
---------
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
New Tier 3 platform: `riscv64` architecture is now included, allowing
the collector to be built and distributed for this platform.
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#13462
X-Ref:
https://github.com/open-telemetry/opentelemetry-collector-releases/pull/969
<!--Describe what testing was performed and which tests were added.-->
#### Testing
I’ve performed basic compilation as well as starting collector inside a
linux/riscv64 container (`docker.io/riscv64/debian`).
<!--Describe the documentation added.-->
#### Documentation
Added myself as a contact point to `platform-support.md` document.
---------
Signed-off-by: Mateusz Urbanek <mateusz.urbanek.98@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
Moves 'releases' release process to opentelemetry-collector-contrib
repository.
Depends on open-telemetry/opentelemetry-collector-releases/pull/1034.
See also #13463 and
open-telemetry/opentelemetry-collector-contrib/pull/41509.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Moves contrib release process to opentelemetry-collector-contrib
repository.
Depends on open-telemetry/opentelemetry-collector-contrib/pull/41509.
See also #13464 and
open-telemetry/opentelemetry-collector-releases/pull/1034
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Updates release doc to split into core, contrib and 'releases' release
managers.
Includes list of people.
<!-- Issue number if applicable -->
#### Link to tracking issue
Updates #13314
---------
Co-authored-by: Damien Mathieu <42@dmathieu.com>
#### Description
This PR updates the [Pipeline Component Telemetry
RFC](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/rfcs/component-universal-telemetry.md)
with the following changes:
- Reflect implementation choices that have been made since the RFC was
written:
1. using instrumentation scope attributes instead of datapoint
attributes to identify component instances
(see discussion in #12217 and
https://github.com/open-telemetry/opentelemetry-go/issues/6404)
2. automatically injecting these attributes, without changes to
component code
3. changing the instrumentation scope name used for pipeline metrics
- Slightly change the semantics of `outcome = refused`:
The current planned behavior (from #11956) is that, in the case of a
pipeline A → B where component B returns an error, the "consumed" metric
for B and the "produced" metric for A should both have `outcome =
failure`.
I fear that this may lead users to think that a failure occurred in A,
and would like to restrict `outcome = failure` to only be associated
with the component that "failed", ie. component B. The "produced" metric
associated with A would instead have `outcome = refused`.
This incidentally makes implementation slightly easier, since an
instrumentation layer will not need different error wrapping behavior
between the "producer" layer and the "consumer" layer.
See draft PR #13234 for an example implementation.
As this is a non-trivial change to an RFC, it may need to follow the RFC
process.
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
A few changes:
- Update the section about releasing `collector-contrib` to reflect the
fact that the Github release is now automatically populated with the
changelog
(https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/38730)
- Update recommendations for dealing with
https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/47
with a new workaround (commenting out the unrecognized "merge" entries
in `.git/config`)
- Remove what looks like a second reference to the same issue?
- Put myself and Bogdan back at the end of the release rotation
- Correct the date for the release of v0.137.0, which is only one week
after v0.136.0. Feel free to tell me if this wasn't a mistake.
<!--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
Pablo Baeyens
Antoine Toulme
Evan Bradley
Moritz Wiesinger
Alex Boten
Mateusz Urbanek
Andrzej Stencel
Jade Guiton
Joshua MacDonald
John L. Peterson (Jack)
Roger Coll
Christos Markou
Juliano Costa
Dmitry Anoshin
Daniel Jaglowski
Yang Song
Bogdan Drutu
Juraci Paixão Kröhling
Tyler Helmuth
Yuri Sa
Benjamin Blattberg