From 57d8b3a0f79bb2ed3f89341bb84eb20b120529ae Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 21:30:34 +0100 Subject: [PATCH 01/17] new project: system packages --- projects/packaging.md | 112 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 projects/packaging.md diff --git a/projects/packaging.md b/projects/packaging.md new file mode 100644 index 000000000..94e019579 --- /dev/null +++ b/projects/packaging.md @@ -0,0 +1,112 @@ +# OpenTelemetry System Packaging + +The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](http://github.com/open-telemetry/opentelemetry-injector[]) injecting SDKs and autoinstrumentations, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. + +This SIG takes over and continues work about system packaging started in the Injector SIG (see [project](https://github.com/open-telemetry/community/pull/3097)), joining forces with the OBI SIG to provide a cohesive experience and better coverage for the various application runtimes. +The ultimate goal is to provide an excellent experience via: + +```shell +{apt|yum} install opentelemetry +``` + +**Note:** Due to the predominance of adoption of Linux as the “Cloud computing” OS, and specifically Debian and Red Hat distros, the SIG focuses on system packages for the DEB and RPM ecosystem. Windows is an OS that we acknowledge also needs a simple OpenTelemetry experience, but it is out of the initial scope for reasons of priorities, bandwidth and lack of expertise in the founding members of the SIG. +**Note:** The deliverables of the Profiler SIG would likely also benefit from being packaged. This is out of scope for the foreseeable future for reasons of priorities and bandwidth in the founding members of the SIG. + +## Background and description + +### Current challenges + +Adopting OpenTelemetry can be a difficult task for most users without significant expertise in observability. Modifying applications to add and maintain SDKs and their setup is a chore that most developers would rather avoid. A lot of practitioners, and especially those without expert-level skills in observability (which is the overwhelming majority of people out there needing observability) are perfectly fine starting their observability journey by using auto-instrumentations, especially for those languages with good instrumentation coverage and mature SDKs. + +Packaging OBI, the OpenTelemetry Injector and auto-instrumentations in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. + +### Goals, objectives, and requirements + +#### Goals + +Create the infrastructure to publish APT and RPM repositories for OpenTelemetry system packages +We would love to explore publishing the packages in universe (Debian, Ubuntu) and EPEL (RHEL) repositories, as opposed to creating separate repositories; but we acknowledge that, as long as the packaging and associated policies are mature, we will likely need to host OpenTelemetry-specific package repositories. +Publish modular, well-integrated system packages for: +* OBI +* OpenTelemetry Injector +* SDK+autoinstrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) +* Make the existing OpenTelemetry Collector system packages from the Releases project in the APT and RPM repositories +* Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat +* Make declarative configuration a first-class citizen of the system packages + +#### Why now? + +We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from auto-instrumentations straightforward and seamless. + +#### Requirements + +* **Enterprise-ready:** The OpenTelemetry package repositories must be easy to add a trusted package repository to the Linux system. +* **Easy mode is easy:** `{apt|yum} install opentelemetry` and some lightweight configurations in `/etc` should be all the user needs to do to set up autoinstrumentation of the applications running on the system. +**Note:** There is much more we could do to configure the collector, e.g., automatically set up syslog / journald receivers, host resource detectors, and more. But that is outside the current scope. +* **Cohesive:** OBI and the Injector need to “play nice together,” to avoid double instrumentation of processes that both support. Whether OBI or the Injector have precedence over one another, or whether they are “alternatives” (as in: packages that cannot be installed at the same time, but fulfill the requirement set out by the same meta-package) is TBD. +* **Declarative configuration:** OBI and the SDKs injected by the OpenTelemetry Injector should default to using declarative configuration. +* **Packaging best practices:** The system packages must adhere to the best practices set out by the ecosystem in terms of modularity, uninstall, interdependencies, licensing metadata, etc. +* **Filesystem Hierarchy Standard (FHS):** The system packages need to respect the best practices set out by the FHS, both in terms of executable files and configurations. +* **Collector:** The system packages for OBI and the Injector should be aware whether a Collector system package is also installed, and preferentially route telemetry through it. +* **Stretch goals:** + * Ruby support via the Injector + * PHP support via the Injector + * Useful MAN pages + +#### Benefits + +Idiomatic, dead-simple process to monitor applications running in Linux virtual hosts with the same tooling used to deploy (most of) the software to monitor. +The Injector and AutoInstrumentation packages would likely also be reusable while building container images, but that is not a primary goal at this time. + +## Deliverables + +TODO + +## Staffing / Help Wanted + +### Industry outreach (Optional) + +[Michele](https://github.com/mmanciop) tried to reach out to Canonical for help with DEB packaging, but while generally interested, they have not committed to helping. + +Need more expertise in packaging RPM, right now the expertise in the SIG is mostly with DEB + +### SIG + +otel-packaging + +### Staffing + +TODO + +### Sponsorship + +See [Project Sponsorship](/project-management.md#project-sponsorship) + +#### TC Sponsor + +Name of TC sponsor + +#### Delegated TC Sponsor (Optional) + +Name of delegated TC sponsor + +#### GC Liaison + +Ted Young + +## Expected Timeline + +TODO + +## Labels (Optional) + +*Issues should be properly labeled to indicate what parts of the specification it is focused on. List here the labels applicable to this project, and consider adding them to corresponding GitHub Project automation to include them automatically into the project backlog.* + +## GitHub Project (Post-Approval) + +## SIG Meetings, Roadmap, and Other Info (Post-Approval) + +Repo: TODO + +SIG Meeting + From 8a6540d470eba9dfb30e75f42811084fa695ae83 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 21:36:53 +0100 Subject: [PATCH 02/17] fix: restore links that got lost in GDocs -> Markdown move --- projects/packaging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/packaging.md b/projects/packaging.md index 94e019579..53813eb67 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -30,9 +30,9 @@ Publish modular, well-integrated system packages for: * OBI * OpenTelemetry Injector * SDK+autoinstrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) -* Make the existing OpenTelemetry Collector system packages from the Releases project in the APT and RPM repositories +* Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories * Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat -* Make declarative configuration a first-class citizen of the system packages +* Make [declarative configuration](https://github.com/open-telemetry/opentelemetry-configuration) a first-class citizen of the system packages #### Why now? From de68129090da54371df3ab1558e7835ee2d2066d Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 21:40:40 +0100 Subject: [PATCH 03/17] fix: lint --- projects/packaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/packaging.md b/projects/packaging.md index 53813eb67..80c01a2c9 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -1,6 +1,6 @@ # OpenTelemetry System Packaging -The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](http://github.com/open-telemetry/opentelemetry-injector[]) injecting SDKs and autoinstrumentations, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. +The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](https://github.com/open-telemetry/opentelemetry-injector) injecting SDKs and autoinstrumentations, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. This SIG takes over and continues work about system packaging started in the Injector SIG (see [project](https://github.com/open-telemetry/community/pull/3097)), joining forces with the OBI SIG to provide a cohesive experience and better coverage for the various application runtimes. The ultimate goal is to provide an excellent experience via: From 3261208ba5af6f322f445d07acf8102a77720dce Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 22:18:52 +0100 Subject: [PATCH 04/17] chore: add needed words to cspell --- .cspell.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.cspell.yaml b/.cspell.yaml index 70ef66e7b..56fb24736 100644 --- a/.cspell.yaml +++ b/.cspell.yaml @@ -24,6 +24,7 @@ words: - Aronoff - Ashpole - automations + - autoinstrumentation - Baeyens - calendar-localization-ptbr - Causely @@ -47,6 +48,7 @@ words: - eiffel - elastic - emea + - EPEL - faas - gitter - grafana From f02334c0ce7c46a9f50492c476d81e0eb0d2b340 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 22:24:51 +0100 Subject: [PATCH 05/17] spell check and document vendor extensibility --- projects/packaging.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/projects/packaging.md b/projects/packaging.md index 80c01a2c9..d06cffd68 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -1,6 +1,6 @@ # OpenTelemetry System Packaging -The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](https://github.com/open-telemetry/opentelemetry-injector) injecting SDKs and autoinstrumentations, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. +The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](https://github.com/open-telemetry/opentelemetry-injector) injecting SDKs and autoinstrumentation packages, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. This SIG takes over and continues work about system packaging started in the Injector SIG (see [project](https://github.com/open-telemetry/community/pull/3097)), joining forces with the OBI SIG to provide a cohesive experience and better coverage for the various application runtimes. The ultimate goal is to provide an excellent experience via: @@ -9,7 +9,7 @@ The ultimate goal is to provide an excellent experience via: {apt|yum} install opentelemetry ``` -**Note:** Due to the predominance of adoption of Linux as the “Cloud computing” OS, and specifically Debian and Red Hat distros, the SIG focuses on system packages for the DEB and RPM ecosystem. Windows is an OS that we acknowledge also needs a simple OpenTelemetry experience, but it is out of the initial scope for reasons of priorities, bandwidth and lack of expertise in the founding members of the SIG. +**Note:** Due to the predominance of adoption of Linux as the “Cloud computing” OS, and specifically Debian and Red Hat distributions, the SIG focuses on system packages for the DEB and RPM ecosystem. Windows is an OS that we acknowledge also needs a simple OpenTelemetry experience, but it is out of the initial scope for reasons of priorities, bandwidth and lack of expertise in the founding members of the SIG. **Note:** The deliverables of the Profiler SIG would likely also benefit from being packaged. This is out of scope for the foreseeable future for reasons of priorities and bandwidth in the founding members of the SIG. ## Background and description @@ -18,25 +18,26 @@ The ultimate goal is to provide an excellent experience via: Adopting OpenTelemetry can be a difficult task for most users without significant expertise in observability. Modifying applications to add and maintain SDKs and their setup is a chore that most developers would rather avoid. A lot of practitioners, and especially those without expert-level skills in observability (which is the overwhelming majority of people out there needing observability) are perfectly fine starting their observability journey by using auto-instrumentations, especially for those languages with good instrumentation coverage and mature SDKs. -Packaging OBI, the OpenTelemetry Injector and auto-instrumentations in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. +Packaging OBI, the OpenTelemetry Injector and autoinstrumentations in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. ### Goals, objectives, and requirements #### Goals -Create the infrastructure to publish APT and RPM repositories for OpenTelemetry system packages -We would love to explore publishing the packages in universe (Debian, Ubuntu) and EPEL (RHEL) repositories, as opposed to creating separate repositories; but we acknowledge that, as long as the packaging and associated policies are mature, we will likely need to host OpenTelemetry-specific package repositories. -Publish modular, well-integrated system packages for: -* OBI -* OpenTelemetry Injector -* SDK+autoinstrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) -* Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories -* Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat -* Make [declarative configuration](https://github.com/open-telemetry/opentelemetry-configuration) a first-class citizen of the system packages +* Create the infrastructure to publish APT and RPM repositories for OpenTelemetry system packages. + * We would love to explore publishing the packages in universe (Debian, Ubuntu) and EPEL (RHEL) repositories, as opposed to creating separate repositories; but we acknowledge that, as long as the packaging and associated policies are mature, we will likely need to host OpenTelemetry-specific package repositories. +* Publish modular, well-integrated system packages for: + * OBI + * OpenTelemetry Injector + * SDK+autoinstrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) +* Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories. +* Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat. +* Extensible to vendor packages: It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and autoinstrumentation system packages. +* Make [declarative configuration](https://github.com/open-telemetry/opentelemetry-configuration) a first-class citizen of the system packages. #### Why now? -We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from auto-instrumentations straightforward and seamless. +We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from autoinstrumentations straightforward and seamless. #### Requirements @@ -44,6 +45,7 @@ We feel OpenTelemetry needs to provide a more product-like, batteries-included e * **Easy mode is easy:** `{apt|yum} install opentelemetry` and some lightweight configurations in `/etc` should be all the user needs to do to set up autoinstrumentation of the applications running on the system. **Note:** There is much more we could do to configure the collector, e.g., automatically set up syslog / journald receivers, host resource detectors, and more. But that is outside the current scope. * **Cohesive:** OBI and the Injector need to “play nice together,” to avoid double instrumentation of processes that both support. Whether OBI or the Injector have precedence over one another, or whether they are “alternatives” (as in: packages that cannot be installed at the same time, but fulfill the requirement set out by the same meta-package) is TBD. +* **Extensible to vendor packages:** It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and autoinstrumentation system packages. * **Declarative configuration:** OBI and the SDKs injected by the OpenTelemetry Injector should default to using declarative configuration. * **Packaging best practices:** The system packages must adhere to the best practices set out by the ecosystem in terms of modularity, uninstall, interdependencies, licensing metadata, etc. * **Filesystem Hierarchy Standard (FHS):** The system packages need to respect the best practices set out by the FHS, both in terms of executable files and configurations. @@ -55,7 +57,7 @@ We feel OpenTelemetry needs to provide a more product-like, batteries-included e #### Benefits -Idiomatic, dead-simple process to monitor applications running in Linux virtual hosts with the same tooling used to deploy (most of) the software to monitor. +Idiomatic, dead-simple process to set up the monitoring of applications running in Linux virtual hosts with the same tooling used to deploy (most of) the software to monitor. The Injector and AutoInstrumentation packages would likely also be reusable while building container images, but that is not a primary goal at this time. ## Deliverables From 33b23eb9a9f81df8a3d4f20aeb9e63245129916e Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 22:25:42 +0100 Subject: [PATCH 06/17] add missing line break --- projects/packaging.md | 1 + 1 file changed, 1 insertion(+) diff --git a/projects/packaging.md b/projects/packaging.md index d06cffd68..1b1fd18a4 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -10,6 +10,7 @@ The ultimate goal is to provide an excellent experience via: ``` **Note:** Due to the predominance of adoption of Linux as the “Cloud computing” OS, and specifically Debian and Red Hat distributions, the SIG focuses on system packages for the DEB and RPM ecosystem. Windows is an OS that we acknowledge also needs a simple OpenTelemetry experience, but it is out of the initial scope for reasons of priorities, bandwidth and lack of expertise in the founding members of the SIG. + **Note:** The deliverables of the Profiler SIG would likely also benefit from being packaged. This is out of scope for the foreseeable future for reasons of priorities and bandwidth in the founding members of the SIG. ## Background and description From 7b73c3395a1362b110a9aaf7729b99c88ee89617 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 22:28:25 +0100 Subject: [PATCH 07/17] start staffing --- projects/packaging.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/projects/packaging.md b/projects/packaging.md index 1b1fd18a4..06f3a96e7 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -67,9 +67,13 @@ TODO ## Staffing / Help Wanted +[`@mmanciop`](https://github.com/mmanciop) (Dash0): DEB system packages, injector + +TODO + ### Industry outreach (Optional) -[Michele](https://github.com/mmanciop) tried to reach out to Canonical for help with DEB packaging, but while generally interested, they have not committed to helping. +[`@mmanciop`](https://github.com/mmanciop) tried to reach out to Canonical for help with DEB packaging, but while generally interested, they have not committed to helping. Need more expertise in packaging RPM, right now the expertise in the SIG is mostly with DEB From c7a49f4395ea48ebc95968ba7014306a4ff0e9b1 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Tue, 3 Feb 2026 22:35:26 +0100 Subject: [PATCH 08/17] chore: persevere in the cspell struggle about autoinstrumentation --- projects/packaging.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/projects/packaging.md b/projects/packaging.md index 06f3a96e7..c0b99eb5e 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -17,9 +17,9 @@ The ultimate goal is to provide an excellent experience via: ### Current challenges -Adopting OpenTelemetry can be a difficult task for most users without significant expertise in observability. Modifying applications to add and maintain SDKs and their setup is a chore that most developers would rather avoid. A lot of practitioners, and especially those without expert-level skills in observability (which is the overwhelming majority of people out there needing observability) are perfectly fine starting their observability journey by using auto-instrumentations, especially for those languages with good instrumentation coverage and mature SDKs. +Adopting OpenTelemetry can be a difficult task for most users without significant expertise in observability. Modifying applications to add and maintain SDKs and their setup is a chore that most developers would rather avoid. A lot of practitioners, and especially those without expert-level skills in observability (which is the overwhelming majority of people out there needing observability) are perfectly fine starting their observability journey by using autoinstrumentation, especially for those languages with good instrumentation coverage and mature SDKs. -Packaging OBI, the OpenTelemetry Injector and autoinstrumentations in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. +Packaging OBI, the OpenTelemetry Injector and language-specific autoinstrumentation in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. ### Goals, objectives, and requirements @@ -38,7 +38,7 @@ Packaging OBI, the OpenTelemetry Injector and autoinstrumentations in system pac #### Why now? -We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from autoinstrumentations straightforward and seamless. +We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from autoinstrumentation straightforward and seamless. #### Requirements From e57c4fbe45ca9de333ad20f02ba28c35f23f5e29 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Wed, 4 Feb 2026 04:25:20 +0100 Subject: [PATCH 09/17] add `atoulme` to project staff Co-authored-by: Antoine Toulme --- projects/packaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/packaging.md b/projects/packaging.md index c0b99eb5e..802983ea4 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -68,7 +68,7 @@ TODO ## Staffing / Help Wanted [`@mmanciop`](https://github.com/mmanciop) (Dash0): DEB system packages, injector - +[`@atoulme`](https://github.com/atoulme) (Splunk): System packages, injector, collector, Java ecosystem TODO ### Industry outreach (Optional) From 5a5043c93a3beba98e071ab1b521f82a7e010476 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Thu, 5 Feb 2026 22:39:01 +0100 Subject: [PATCH 10/17] chore: use consistently auto-instrumentation --- .cspell.yaml | 1 - projects/packaging.md | 18 +++++++++--------- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/.cspell.yaml b/.cspell.yaml index 56fb24736..97b6d3695 100644 --- a/.cspell.yaml +++ b/.cspell.yaml @@ -24,7 +24,6 @@ words: - Aronoff - Ashpole - automations - - autoinstrumentation - Baeyens - calendar-localization-ptbr - Causely diff --git a/projects/packaging.md b/projects/packaging.md index 802983ea4..a495b87cf 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -1,6 +1,6 @@ # OpenTelemetry System Packaging -The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](https://github.com/open-telemetry/opentelemetry-injector) injecting SDKs and autoinstrumentation packages, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. +The goal of the Packaging SIG is to provide a product-like, idiomatic experience to provide a seamless experience of monitoring applications running on (virtual) hosts through a combination of the [OpenTelemetry Injector](https://github.com/open-telemetry/opentelemetry-injector) injecting SDKs and auto-instrumentation packages, [OpenTelemetry eBPF Instrumentation (OBI)](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation), and the OpenTelemetry Collector. This SIG takes over and continues work about system packaging started in the Injector SIG (see [project](https://github.com/open-telemetry/community/pull/3097)), joining forces with the OBI SIG to provide a cohesive experience and better coverage for the various application runtimes. The ultimate goal is to provide an excellent experience via: @@ -17,9 +17,9 @@ The ultimate goal is to provide an excellent experience via: ### Current challenges -Adopting OpenTelemetry can be a difficult task for most users without significant expertise in observability. Modifying applications to add and maintain SDKs and their setup is a chore that most developers would rather avoid. A lot of practitioners, and especially those without expert-level skills in observability (which is the overwhelming majority of people out there needing observability) are perfectly fine starting their observability journey by using autoinstrumentation, especially for those languages with good instrumentation coverage and mature SDKs. +Adopting OpenTelemetry can be a difficult task for most users without significant expertise in observability. Modifying applications to add and maintain SDKs and their setup is a chore that most developers would rather avoid. A lot of practitioners, and especially those without expert-level skills in observability (which is the overwhelming majority of people out there needing observability) are perfectly fine starting their observability journey by using auto-instrumentation, especially for those languages with good instrumentation coverage and mature SDKs. -Packaging OBI, the OpenTelemetry Injector and language-specific autoinstrumentation in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. +Packaging OBI, the OpenTelemetry Injector and language-specific auto-instrumentation in system packages, modular and well integrated with the existing OpenTelemetry Collector system packages, will provide an easy, satisfactory experience for users needing to monitor applications running on Linux-based (virtual) hosts. An {apt|yum} install opentelemetry experience that results in non-containerized applications monitored out of the box is going to allow ops personas to gain observability with a workflow they are familiar with, and to be able to “deploy OpenTelemetry at scale” with tools they already use in their workflows. ### Goals, objectives, and requirements @@ -30,23 +30,23 @@ Packaging OBI, the OpenTelemetry Injector and language-specific autoinstrumentat * Publish modular, well-integrated system packages for: * OBI * OpenTelemetry Injector - * SDK+autoinstrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) + * SDK+auto-instrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) * Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories. * Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat. -* Extensible to vendor packages: It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and autoinstrumentation system packages. +* Extensible to vendor packages: It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and auto-instrumentation system packages. * Make [declarative configuration](https://github.com/open-telemetry/opentelemetry-configuration) a first-class citizen of the system packages. #### Why now? -We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from autoinstrumentation straightforward and seamless. +We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from auto-instrumentation straightforward and seamless. #### Requirements * **Enterprise-ready:** The OpenTelemetry package repositories must be easy to add a trusted package repository to the Linux system. -* **Easy mode is easy:** `{apt|yum} install opentelemetry` and some lightweight configurations in `/etc` should be all the user needs to do to set up autoinstrumentation of the applications running on the system. +* **Easy mode is easy:** `{apt|yum} install opentelemetry` and some lightweight configurations in `/etc` should be all the user needs to do to set up auto-instrumentation of the applications running on the system. **Note:** There is much more we could do to configure the collector, e.g., automatically set up syslog / journald receivers, host resource detectors, and more. But that is outside the current scope. * **Cohesive:** OBI and the Injector need to “play nice together,” to avoid double instrumentation of processes that both support. Whether OBI or the Injector have precedence over one another, or whether they are “alternatives” (as in: packages that cannot be installed at the same time, but fulfill the requirement set out by the same meta-package) is TBD. -* **Extensible to vendor packages:** It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and autoinstrumentation system packages. +* **Extensible to vendor packages:** It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and auto-instrumentation system packages. * **Declarative configuration:** OBI and the SDKs injected by the OpenTelemetry Injector should default to using declarative configuration. * **Packaging best practices:** The system packages must adhere to the best practices set out by the ecosystem in terms of modularity, uninstall, interdependencies, licensing metadata, etc. * **Filesystem Hierarchy Standard (FHS):** The system packages need to respect the best practices set out by the FHS, both in terms of executable files and configurations. @@ -59,7 +59,7 @@ We feel OpenTelemetry needs to provide a more product-like, batteries-included e #### Benefits Idiomatic, dead-simple process to set up the monitoring of applications running in Linux virtual hosts with the same tooling used to deploy (most of) the software to monitor. -The Injector and AutoInstrumentation packages would likely also be reusable while building container images, but that is not a primary goal at this time. +The Injector and auto-instrumentation packages would likely also be reusable while building container images, but that is not a primary goal at this time. ## Deliverables From 66fe31d66762f8dd71ec57dac51814daca97219d Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Thu, 5 Feb 2026 23:10:05 +0100 Subject: [PATCH 11/17] add x1unix to the list of people committing to do the work Co-authored-by: Denys Sedchenko <9203548+x1unix@users.noreply.github.com> --- projects/packaging.md | 1 + 1 file changed, 1 insertion(+) diff --git a/projects/packaging.md b/projects/packaging.md index a495b87cf..250a620b9 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -69,6 +69,7 @@ TODO [`@mmanciop`](https://github.com/mmanciop) (Dash0): DEB system packages, injector [`@atoulme`](https://github.com/atoulme) (Splunk): System packages, injector, collector, Java ecosystem +[`@x1unix`](https://github.com/x1unix) (Grafana Labs): DEB/RPM system packages TODO ### Industry outreach (Optional) From f64c25d95165dffc3d5d84c14394fe040e36085a Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Fri, 6 Feb 2026 18:01:16 +0100 Subject: [PATCH 12/17] chore: Add Douglas Camata to staffing, specify out of scope section --- projects/packaging.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/projects/packaging.md b/projects/packaging.md index 250a620b9..a482409ea 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -9,10 +9,6 @@ The ultimate goal is to provide an excellent experience via: {apt|yum} install opentelemetry ``` -**Note:** Due to the predominance of adoption of Linux as the “Cloud computing” OS, and specifically Debian and Red Hat distributions, the SIG focuses on system packages for the DEB and RPM ecosystem. Windows is an OS that we acknowledge also needs a simple OpenTelemetry experience, but it is out of the initial scope for reasons of priorities, bandwidth and lack of expertise in the founding members of the SIG. - -**Note:** The deliverables of the Profiler SIG would likely also benefit from being packaged. This is out of scope for the foreseeable future for reasons of priorities and bandwidth in the founding members of the SIG. - ## Background and description ### Current challenges @@ -36,6 +32,14 @@ Packaging OBI, the OpenTelemetry Injector and language-specific auto-instrumenta * Extensible to vendor packages: It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and auto-instrumentation system packages. * Make [declarative configuration](https://github.com/open-telemetry/opentelemetry-configuration) a first-class citizen of the system packages. +#### Out of scope + +* **OS other than Debian- and RHEL derivatives:** Due to the predominance of adoption of Linux as the “Cloud computing” OS, and specifically Debian and Red Hat distributions, the SIG focuses on system packages for the DEB and RPM ecosystem. Windows is an OS that we acknowledge also needs a simple OpenTelemetry experience, but it is out of the initial scope for reasons of priorities, bandwidth and lack of expertise in the founding members of the SIG. + +* **Profilers:** The deliverables of the Profiler SIG would likely also benefit from being packaged. This is out of scope for the foreseeable future for reasons of priorities and bandwidth in the founding members of the SIG. + +* **Building container images:** While the OpenTelemetry Injector and auto-instrumentation packages would likely be reusable for building container images, this is not a primary goal at this time. On Kubernetes, the auto-instrumentation by the OpenTelemetry Operator provides a better, more flexible experience than "hardcoding" auto-instrumentations in the container image. However, if we see feedback from the community asking for support for the "Docker on (virtual) host" scenario, adding it to the scope should be possible with relatively little effort. + #### Why now? We feel OpenTelemetry needs to provide a more product-like, batteries-included experience to newcomers, especially operators used to the ease of adoption of some proprietary vendors. This is especially critical for organizations in which operators are in charge of maintaining observability setups, without the ability of modifying single applications. We want to make the experience of getting library-level telemetry from auto-instrumentation straightforward and seamless. @@ -59,7 +63,6 @@ We feel OpenTelemetry needs to provide a more product-like, batteries-included e #### Benefits Idiomatic, dead-simple process to set up the monitoring of applications running in Linux virtual hosts with the same tooling used to deploy (most of) the software to monitor. -The Injector and auto-instrumentation packages would likely also be reusable while building container images, but that is not a primary goal at this time. ## Deliverables @@ -70,6 +73,8 @@ TODO [`@mmanciop`](https://github.com/mmanciop) (Dash0): DEB system packages, injector [`@atoulme`](https://github.com/atoulme) (Splunk): System packages, injector, collector, Java ecosystem [`@x1unix`](https://github.com/x1unix) (Grafana Labs): DEB/RPM system packages +[`@douglascamata`](https://github.com/douglascamata) (Coralogix): system packages, collector, Ruby, Python + TODO ### Industry outreach (Optional) From e18a2188bf5de3da7ad0d0a9cb6a2e964f57aed3 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Mon, 9 Feb 2026 20:16:11 +0100 Subject: [PATCH 13/17] Correct refuse mistaking PHP for Python --- projects/packaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/packaging.md b/projects/packaging.md index a482409ea..296716847 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -26,7 +26,7 @@ Packaging OBI, the OpenTelemetry Injector and language-specific auto-instrumenta * Publish modular, well-integrated system packages for: * OBI * OpenTelemetry Injector - * SDK+auto-instrumentation for Java, .NET, Node.js and Python (with potentially Python and Ruby if bandwidth allows) + * SDK+auto-instrumentation for Java, .NET, Node.js and Python (with potentially PHP and Ruby if bandwidth allows) * Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories. * Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat. * Extensible to vendor packages: It should be possible for vendor system packages to provide alternatives to upstream system packages, especially for collector and auto-instrumentation system packages. From 7d70649db44bd3768b83f3910266ff3288c4c3fa Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Mon, 9 Feb 2026 21:18:25 +0100 Subject: [PATCH 14/17] Specify that the focus for OBI is going to be Go --- projects/packaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/packaging.md b/projects/packaging.md index 296716847..e70111bb8 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -24,7 +24,7 @@ Packaging OBI, the OpenTelemetry Injector and language-specific auto-instrumenta * Create the infrastructure to publish APT and RPM repositories for OpenTelemetry system packages. * We would love to explore publishing the packages in universe (Debian, Ubuntu) and EPEL (RHEL) repositories, as opposed to creating separate repositories; but we acknowledge that, as long as the packaging and associated policies are mature, we will likely need to host OpenTelemetry-specific package repositories. * Publish modular, well-integrated system packages for: - * OBI + * OBI, with focus on Go * OpenTelemetry Injector * SDK+auto-instrumentation for Java, .NET, Node.js and Python (with potentially PHP and Ruby if bandwidth allows) * Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories. From 5cb927ce1de3d566b5384d0bdfd6777a2d1d73c2 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Wed, 11 Feb 2026 13:53:33 +0100 Subject: [PATCH 15/17] Update OBI focus in packaging documentation Clarified focus on Go for OBI to prevent double instrumentation with other languages. --- projects/packaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/packaging.md b/projects/packaging.md index e70111bb8..6808aebdf 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -24,8 +24,8 @@ Packaging OBI, the OpenTelemetry Injector and language-specific auto-instrumenta * Create the infrastructure to publish APT and RPM repositories for OpenTelemetry system packages. * We would love to explore publishing the packages in universe (Debian, Ubuntu) and EPEL (RHEL) repositories, as opposed to creating separate repositories; but we acknowledge that, as long as the packaging and associated policies are mature, we will likely need to host OpenTelemetry-specific package repositories. * Publish modular, well-integrated system packages for: - * OBI, with focus on Go * OpenTelemetry Injector + * OBI, with focus on Go to avoid double instrumentation with other languages that have already better support from other OTEL components. * SDK+auto-instrumentation for Java, .NET, Node.js and Python (with potentially PHP and Ruby if bandwidth allows) * Make the existing OpenTelemetry Collector system packages from the [Releases repository](https://github.com/open-telemetry/opentelemetry-collector-releases) in the APT and RPM repositories. * Define versioning policies and how they align with the packaging versioning policies of Debian, Ubuntu and Red Hat. From 41b103d424bfb444b1784e94d05ab707cebce349 Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Mon, 23 Feb 2026 18:52:23 +0100 Subject: [PATCH 16/17] Remove TODO section from packaging.md Removed TODO section from packaging.md --- projects/packaging.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/projects/packaging.md b/projects/packaging.md index 6808aebdf..bd43fd9fd 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -75,8 +75,6 @@ TODO [`@x1unix`](https://github.com/x1unix) (Grafana Labs): DEB/RPM system packages [`@douglascamata`](https://github.com/douglascamata) (Coralogix): system packages, collector, Ruby, Python -TODO - ### Industry outreach (Optional) [`@mmanciop`](https://github.com/mmanciop) tried to reach out to Canonical for help with DEB packaging, but while generally interested, they have not committed to helping. From d1c874b765181646864366e18b74f10663267dad Mon Sep 17 00:00:00 2001 From: Michele Mancioppi Date: Mon, 23 Feb 2026 18:53:52 +0100 Subject: [PATCH 17/17] Remove duplicated Staffing section from packaging.md Removed the Staffing section and its TODO note. --- projects/packaging.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/projects/packaging.md b/projects/packaging.md index bd43fd9fd..d01ab8e2b 100644 --- a/projects/packaging.md +++ b/projects/packaging.md @@ -85,10 +85,6 @@ Need more expertise in packaging RPM, right now the expertise in the SIG is most otel-packaging -### Staffing - -TODO - ### Sponsorship See [Project Sponsorship](/project-management.md#project-sponsorship)