Background

The operator-opamp-bridge is currently bundled within this repository and tightly coupled to the OpenTelemetryCollector CRD. It acts as the Kubernetes-native equivalent of the OpAMP Supervisor: it connects to an OpAMP server, receives remote configurations, and applies them by creating/updating OpenTelemetryCollector custom resources via controller-runtime.

This model requires the OpenTelemetry Operator to be installed in the cluster. However, there is a significant set of users who:

• Run collectors deployed as plain Deployments/DaemonSets with Kubernetes ConfigMap-based configuration (no operator CRD installed),
• Want remote configuration management via OpAMP without adopting the full operator stack,
• Use GitOps tooling (e.g., ArgoCD, Flux) where the collector workload is managed externally, but the collector config (a ConfigMap) can be updated independently.

Problem statement

Today, there is no supported way to use OpAMP remote configuration to update a collector's ConfigMap directly in Kubernetes. Users must choose between:

1. Installing the full OpenTelemetry Operator and using the OpenTelemetryCollector CRD, or
2. Managing collector configuration entirely out-of-band (no OpAMP).

Proposed solution

Extract the common OpAMP agent logic from operator-opamp-bridge into a shared library and ship a second standalone binary — a ConfigMap-targeting OpAMP bridge — that:

1. Connects to an OpAMP server (same protocol, same opamp-go client),
2. Receives remote configuration,
3. Applies the configuration by patching Kubernetes ConfigMap objects (rather than OpenTelemetryCollector CRs),
4. Optionally triggers a rolling restart of the collector workload (Deployment/DaemonSet) so the new config is picked up.

Requirements

Shared library / common layer

• The OpAMP client lifecycle (Start, Shutdown, heartbeating, onMessage dispatch, RemoteConfigStatus reporting) should be extracted so both binaries share the same code path.
• The ConfigApplier interface (already defined in internal/operator/client.go) is a natural seam — a ConfigMap-backed implementation would satisfy it without touching the agent or OpAMP protocol logic.
• Health reporting should remain extensible so each backend (CRD vs. ConfigMap) can describe the health of its managed resources appropriately.

Standalone binary (cmd/configmap-opamp-bridge or similar)

• Must run without the OpenTelemetry Operator CRDs being present in the cluster.
• Must be able to identify target ConfigMap(s) by label selectors or explicit name/namespace, matching keys received from the OpAMP server (following the same name/namespace key convention as the existing bridge).
• Must require minimal RBAC: get/update on ConfigMaps and optionally patch on Deployments/DaemonSets for restart signaling.
• Should support the same configuration surface as the existing bridge (endpoint, TLS, headers, capabilities).
• Should not depend on any operator-framework or controller-runtime manager/webhook machinery — a plain Kubernetes client is sufficient.

Out of scope

• Full parity with all OpenTelemetryCollector-specific features (component allow-listing validation, proxy/pass-through mode, per-pod health rollup via the OpAMP proxy).
• Replacing the existing bridge — both binaries should coexist; the operator-managed path remains unchanged.

Why here and not in opamp-go?

The Kubernetes-specific adapter belongs in this repository. The opamp-go library is intentionally Kubernetes-agnostic. The refactoring is purely internal to the operator repository.