Merge branch 'main' into connectortest-own-module

.chloggen/9480-configgrpc-option-wrapper.yaml

@@ -0,0 +1,28 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: 'deprecation'
+
+# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver)
+component: configgrpc
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: "Deprecate `ClientConfig.ToClientConn`/`ServerConfig.ToServer` in favor of `ToClientConnWithOptions`/`ToServerWithOptions`"
+
+# One or more tracking issues or pull requests related to the change
+issues: [9480]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: |
+ Users providing a grpc.DialOption/grpc.ServerOption should now wrap them into
+ a generic option with `WithGrpcDialOption`/`WithGrpcServerOption`.
+
+
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [api]

.chloggen/add-pipeline-module.yaml

@@ -0,0 +1,25 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: new_component
+
+# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver)
+component: pipeline
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Adds new `pipeline` module to house the concept of pipeline ID and Signal.
+
+# One or more tracking issues or pull requests related to the change
+issues: [11209]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext:
+
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [api]

.chloggen/consumertest-profiles-samplecount.yaml

@@ -0,0 +1,20 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: 'enhancement'
+
+# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver)
+component: consumertest
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Introduce SampleCount method in ProfilesSink struct.
+
+# One or more tracking issues or pull requests related to the change
+issues: [11225]
+
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [api]

.chloggen/use-cobra-add-version.yaml

@@ -0,0 +1,20 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: 'enhancement'
+
+# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver)
+component: mdatagen
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Use cobra for the command, add version flag
+
+# One or more tracking issues or pull requests related to the change
+issues: [11196]
+
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user]

Makefile

@@ -304,11 +304,13 @@ check-contrib:
  -replace go.opentelemetry.io/collector/extension/zpagesextension=$(CURDIR)/extension/zpagesextension \
  -replace go.opentelemetry.io/collector/featuregate=$(CURDIR)/featuregate \
  -replace go.opentelemetry.io/collector/internal/globalgates=$(CURDIR)/internal/globalgates \
+ -replace go.opentelemetry.io/collector/internal/globalsignal=$(CURDIR)/internal/globalsignal \
  -replace go.opentelemetry.io/collector/otelcol=$(CURDIR)/otelcol \
  -replace go.opentelemetry.io/collector/otelcol/otelcoltest=$(CURDIR)/otelcol/otelcoltest \
  -replace go.opentelemetry.io/collector/pdata=$(CURDIR)/pdata \
  -replace go.opentelemetry.io/collector/pdata/testdata=$(CURDIR)/pdata/testdata \
  -replace go.opentelemetry.io/collector/pdata/pprofile=$(CURDIR)/pdata/pprofile \
+ -replace go.opentelemetry.io/collector/pipeline=$(CURDIR)/pipeline \
  -replace go.opentelemetry.io/collector/processor=$(CURDIR)/processor \
  -replace go.opentelemetry.io/collector/processor/batchprocessor=$(CURDIR)/processor/batchprocessor \
  -replace go.opentelemetry.io/collector/processor/memorylimiterprocessor=$(CURDIR)/processor/memorylimiterprocessor \
@@ -371,11 +373,13 @@ restore-contrib:
  -dropreplace go.opentelemetry.io/collector/extension/zpagesextension \
  -dropreplace go.opentelemetry.io/collector/featuregate \
  -dropreplace go.opentelemetry.io/collector/internal/globalgates \
+ -dropreplace go.opentelemetry.io/collector/internal/globalsignal \
  -dropreplace go.opentelemetry.io/collector/otelcol \
  -dropreplace go.opentelemetry.io/collector/otelcol/otelcoltest \
  -dropreplace go.opentelemetry.io/collector/pdata \
  -dropreplace go.opentelemetry.io/collector/pdata/testdata \
  -dropreplace go.opentelemetry.io/collector/pdata/pprofile \
+ -dropreplace go.opentelemetry.io/collector/pipeline \
  -dropreplace go.opentelemetry.io/collector/processor \
  -dropreplace go.opentelemetry.io/collector/processor/batchprocessor \
  -dropreplace go.opentelemetry.io/collector/processor/memorylimiterprocessor \

VERSIONING.md

@@ -1,13 +1,42 @@
-# Versioning
+# Versioning and stability
 
-This document describes the versioning policy for this repository. This policy
-is designed so that the following goal can be achieved:
+The OpenTelemetry Collector SIG produces several artifacts for [a variety of audiences](CONTRIBUTING.md#target-audiences). This document describes the versioning and support policy for these artifacts. These policies are designed so that the following goal can be achieved:
 
-**Users are provided a codebase of value that is stable and secure.**
+**Users are provided software artifacts of value that are stable and secure.**
 
-## Public API expectations
+The policies are divided depending on the artifact's target audience. While an artifact is supported, [critical bugs](docs/release.md#bugfix-release-criteria) and security vulnerabilities MUST be addressed. The main criteria for the length of support for an artifact is how easy it is for an artifact's target audience to adapt to disruptive changes.
 
-The following public API expectations apply to all modules in opentelemetry-collector and opentelemetry-collector-contrib.
+These policies reflect the current consensus of the OpenTelemetry Collector SIG. They are subject to change as the project evolves.
+
+## Software artifacts for end users
+
+Software artifacts intended for [end users](CONTRIBUTING.md#end-users) of the OpenTelemetry Collector include 
+- Binary distributions of the OpenTelemetry Collector.
+- Go modules that expose Collector components, such as receivers, processors, connectors, extensions and exporters. 
+
+These artifacts are versioned according to the [semantic versioning v2.0.0](https://semver.org/) specification.
+
+### General considerations
+
+Binary distributions produced by the Collector SIG contain components and features with varying [levels of stability](README.md#stability-levels). We abide by the following principles to relate the Collector's version to the stability of its components and features:
+
+* The Collector's core framework behavior MUST be stable in order for a Collector distribution to be v1.0.0 or higher.
+* Users can easily understand when they are opting in to use a component or feature that is not stable.
+ * The Collector MUST be configurable so that unstable components or features can be excluded ensuring that a fully stable configuration is possible.
+ * The Collector's telemetry (e.g. Collector logs) MUST provide the ability to identify usage of unstable components or features.
+
+### Long-term support after v1
+
+The OpenTelemetry Collector SIG provides long-term support for stable binary distributions of the OpenTelemetry Collector and its components. The following policies apply to long-term support for any major version starting on v1:
+
+* A binary distribution of the OpenTelemetry Collector MUST be supported for a minimum of **one year** after the release of the next major version of said distribution.
+* Components MUST be supported for a minimum of **6 months** after the release of the next major version of said component or after the component has been marked as deprecated. If a component has been deprecated for 6 months it MAY be removed from a binary distribution of the OpenTelemetry Collector. This does not imply a major version change in the Collector distribution.
+
+## Go modules
+
+Go modules are intended to be used by [component developers](CONTRIBUTING.md#component-developers) and [Collector library users](CONTRIBUTING.md#collector-library-users) of the OpenTelemetry Collector
+
+Unless otherwise specified, the following public API expectations apply to all modules in opentelemetry-collector and opentelemetry-collector-contrib.
 As a general rule, stability guarantees of modules versioned as `v1` or higher are aligned with [Go 1 compatibility promise](https://go.dev/doc/go1compat).
 
 ### General Go API considerations
@@ -54,7 +83,7 @@ structure.
 must continue to be valid after a change to the validation rules, except when the configuration struct would cause an error
 on its intended usage (e.g. when calling a method or when passed to any method or function in any module under opentelemetry-collector).
 
-## Versioning and module schema
+### Module versioning and schema
 
 * Versioning of this project will be idiomatic of a Go project using [Go
  modules](https://golang.org/ref/mod#versions).
@@ -135,3 +164,10 @@ on its intended usage (e.g. when calling a method or when passed to any method o
  * Contrib modules will be kept up to date with this project's releases.
 * GitHub releases will be made for all releases.
 * Go modules will be made available at Go package mirrors.
+
+### Long-term support after v1
+
+The OpenTelemetry Collector SIG provides long-term support for stable Go modules. Support for modules depend on the module's [target audiences](CONTRIBUTING.md#target-audiences). The following policies apply to long-term support for any major version starting on v1:
+
+- Modules intended for **component developers** MUST be supported for a minimum of **1 year** after the release of the next major version of said module or after the module has been marked as deprecated.
+- Modules intended for **Collector library users** MUST be supported for a minimum of **6 months** after the release of the next major version of said module or after the module has been marked as deprecated.

cmd/mdatagen/README.md

@@ -57,7 +57,7 @@ You can run `cd cmd/mdatagen && $(GOCMD) install .` to install the `mdatagen` to
 
 ## Contributing to the Metadata Generator
 
-The code for generating the documentation can be found in [loader.go](./internal/loader.go) and the templates for rendering the documentation can be found in [templates](internal/templates).
+The code for generating the documentation can be found in [loader.go](./internal/loader.go) and the templates for rendering the documentation can be found in [templates](./internal/templates).
 When making updates to the metadata generator or introducing support for new functionality:
 
 1. Ensure the [metadata-schema.yaml](./metadata-schema.yaml) and [metadata.yaml](./metadata.yaml) files reflect the changes.

cmd/mdatagen/go.mod

@@ -4,6 +4,7 @@ go 1.22.0
 
 require (
  github.com/google/go-cmp v0.6.0
+ github.com/spf13/cobra v1.8.1
  github.com/stretchr/testify v1.9.0
  go.opentelemetry.io/collector/component v0.109.0
  go.opentelemetry.io/collector/config/configtelemetry v0.109.0
@@ -30,6 +31,7 @@ require (
  github.com/go-viper/mapstructure/v2 v2.1.0 // indirect
  github.com/gogo/protobuf v1.3.2 // indirect
  github.com/google/uuid v1.6.0 // indirect
+ github.com/inconshreveable/mousetrap v1.1.0 // indirect
  github.com/json-iterator/go v1.1.12 // indirect
  github.com/knadh/koanf/maps v0.1.1 // indirect
  github.com/knadh/koanf/providers/confmap v0.1.0 // indirect
@@ -39,6 +41,7 @@ require (
  github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
  github.com/modern-go/reflect2 v1.0.2 // indirect
  github.com/pmezard/go-difflib v1.0.0 // indirect
+ github.com/spf13/pflag v1.0.5 // indirect
  go.opentelemetry.io/collector/consumer/consumerprofiles v0.109.0 // indirect
  go.opentelemetry.io/collector/pdata/pprofile v0.109.0 // indirect
  go.opentelemetry.io/collector/receiver/receiverprofiles v0.109.0 // indirect