Contributions

#10226 proposed native OCI SD in 2022 and was closed - maintainers didn't want concrete cloud SDK clients pulled into the Prometheus binary. #18707 reopened the case after the SD subsystem refactors in #18819 (GCE), #18821 (Kubernetes), and #18824 (Azure) established a closure-based adapter pattern that lets the linker drop unused SDK operations. This implementation follows that pattern: concrete OCI clients stay out of the Discovery struct, only function-typed closures cross the interface boundary, so the binary only pulls in the SDK paths Prometheus actually uses. Builds on the workaround proxy I'd been running (oci-prometheus-sd-proxy) - native SD is the right end state, the proxy was only ever a stopgap until upstream support landed.

The proposal carried a maintenance commitment - respond to discovery/oci issues and PRs, keep the OCI SDK current, run integration validation against a real OCI environment. The follow-ups since lean on that: #19030 exposes the primary VNIC's IPv6 addresses and hostname label so dual-stack instances are discoverable, #19032 collapses per-compartment target groups into one source so targets from deleted compartments don't linger until a restart. Both checked against a production OCI tenancy.

#48137 asked for resources to cover the feature that routes CloudWatch Logs into S3 Tables so you can query via Athena without Firehose or Lambda. A few gotchas: integration is a singleton per account so acceptance tests had to be serialized or they'd hit ConflictException. ListSourcesForS3TableIntegration throws ValidationException: Integration not found when the parent's deleted and that had to be treated as not-found rather than an error. DeleteS3TableIntegration uses a generic smithy ResourceNotFoundException not a typed SDK error. During review the maintainer added Autoflex mapping, a list data source, and more test cases. After merge a user asked what the id is in the integration_arn,id import format - it's a per-association UUID from aws logs list-sources-for-s3-table-integration, Identifier field, not anything in the observabilityadmin API. That became PR #48286.

cilium/hubble#1283: the FlowFilter.Reply proto field and ReplyFilter were already wired into the server-side filter chain - just no hubble observe flags to drive them. Added --reply and --not-reply as mutually exclusive flags following the same pattern as --encrypted/--unencrypted. The tri-state concern raised in the issue is already handled server-side in pkg/hubble/filters/reply.go, so nothing extra needed on the CLI side.

cilium/cilium#26521 asked for the request path on Hubble HTTP metrics and was closed in 2023: a raw path label is unbounded cardinality, every ID and slug becomes its own time series. It reopened in 2024 once the discussion moved to a templated, opt-in design, and CFP-26521 writes that design down so implementation can start. The core move is that the label value is the matched template string itself, not the observed path, so the value set is fixed when config loads - never more than N templates plus one miss value, deterministic across agent restarts. That replaces a runtime cardinality cap with config-time validation of the template count. A new optional pathContext block carries the templates, matched in declaration order, using the Go 1.22 net/http.ServeMux wildcard tokens (/users/{id}, /static/{rest...}); unmatched paths follow an onMiss policy of emit or drop_sample. With no pathContext set, the emitted labels are identical to today.

#414692 was filed in 2023 by a GitLab PM. Customers wanted PDF exports of release docs without CI pipelines or checked-in binaries. Sat unactioned for three years. Initial approach got reworked during review to match an existing pattern from the wiki editor, which simplified things. Merged in nine days, first contribution to GitLab. After merge #602773 surfaced two issues: print styles relied on the server-rendered page structure so a soft Vue Router navigation produced a blank first print, and the dark-mode stylesheet (loaded unconditionally for those users) bled into print as gray text. Follow-up !240468 hides the page chrome directly instead of relying on layout structure, and forces light text colors in print.

#5023 flagged the vendored github.com/cilium/ebpf against CVE-2026-10722, fixed upstream in v0.22.0. cilium/ebpf is not a direct import - it comes in through containerd/cgroups/v3/cgroup2 - so the change is a go get github.com/cilium/ebpf@v0.22.0 in /agent followed by go mod tidy and go mod vendor. v0.22.0 requires go 1.25.0, which matches the module's existing go directive, so no toolchain bump.

The CVE is in the LoadCollectionSpec/BTF parsing path. The agent doesn't reach it: cgroups builds its eBPF device program programmatically and the agent only drives the cpu and memory controllers, so nothing parses attacker-controlled BTF. That makes this a version bump to clear scanners, not a fix for a reachable vulnerability - the distinction went in the PR body so reviewers weren't left assuming an exploitable path in the agent. Verified with GOOS=linux GOARCH=amd64 go build -mod=vendor ./... and a consistent vendor tree.

#2098: the reconciler sent a full PUT every loop, so "manager" claimed ownership of the whole CR. Go's resource.Quantity serializes integers as strings, meaning cpu: 1 gets stored as "1". The next helm upgrade then fails with an SSA type conflict on that field.

Maintainer opened #2121 to move defaulting into a mutating webhook. Aligned on the approach before writing: failurePolicy: Fail since the webhook runs in the same pod, and ControlRabbitmqImage stays in the reconciler as it is enforcement, not defaulting. Also caught and confirmed a module path mismatch in the PROJECT file before scaffolding.

#22860 was a bug I filed about missing Middle East regions. PR #22941 was opened a few months later by someone else to fix it. While reviewing I noticed China regions were already in the list but the endpoint generator used amazonaws.com uniformly - China partition needs amazonaws.com.cn. Fix is simple: any cn- prefixed region gets amazonaws.com.cn, rest stays the same. The ecrPattern regex for URL parsing already handled .cn correctly, just the generator was wrong.

#14153: if k3s gets killed before etcd flushes bootstrap data, the stale snapshot dir carries over to the next start and k3s fatals with no bootstrap data found. The startup test already had the right pattern - every K3sKillServer paired with K3sCleanup(-1, ""). Kubeflags test was just missing those two calls.

Initial approach was TCP socket probes on the webhook port - quick, compliant. Maintainer pushed back during review: TCP probes just tell you a port is open, not that the controller is healthy. Rebuilt it properly: a HealthChecker that tracks informer cache sync state, /healthz/ready and /healthz/live HTTP endpoints on the metrics server, readiness gated on cache sync. Helm deployment updated to use HTTP GET probes on the right port. Controller won't receive traffic until it's actually done syncing.

Built it while native OCI SD was still blocked: prometheus/prometheus#10226 had been closed and HTTP SD was the only path that didn't need cloud-specific code in the Prometheus binary. Proxy runs independently, caches OCI API responses centrally, and handles multi-tenancy at the proxy level so Prometheus config stays clean. Native SD has since merged (prometheus/prometheus#18919), which is the better end state, so the repo is now a public archive - left up as read-only reference for anyone still on an older Prometheus.