[CONTP-1656] feat: Add DatadogInstrumentation CRD#2962
Conversation
|
🎯 Code Coverage (details) 🔗 Commit SHA: 17c1357 | Docs | Datadog PR Page | Give us feedback! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2962 +/- ##
==========================================
+ Coverage 40.91% 41.56% +0.65%
==========================================
Files 324 331 +7
Lines 28743 30816 +2073
==========================================
+ Hits 11760 12810 +1050
- Misses 16129 17113 +984
- Partials 854 893 +39
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b591c31ae4
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| "kind": "DatadogInstrumentation", | ||
| "metadata": { | ||
| "name": "redis-check", | ||
| "namespace": "cache" |
There was a problem hiding this comment.
Remove hard-coded namespace from ALM example
The new DatadogInstrumentation ALM example is pinned to "namespace": "cache", which causes the OLM “Create Example” flow to fail on clusters that don’t already have a cache namespace or where users lack cross-namespace write RBAC. Other examples rely on the user-selected namespace; this one should do the same (or use a placeholder) to avoid a broken out-of-the-box creation path.
Useful? React with 👍 / 👎.
…ent dispatching (#50206) ### What does this PR do? Introduces a `DatadogInstrumentation` CRD controller in the Cluster Agent that watches `DatadogInstrumentation` custom resources and dispatches section-level events (`EventCreate`, `EventUpdate`, `EventDelete`) to product-specific handlers. - **Controller** (`pkg/clusteragent/instrumentation/`): Uses a key-only workqueue with a `lastSeen` store to diff current state (from the informer cache) against the last successfully reconciled state. This gives natural deduplication and prevents stale-snapshot bugs on requeue. - **`Handler` interface**: Product handlers implement `HasSection`, `Handle`, `Validate`, and `SupportsTarget`. Each handler owns a section of the CR spec and only receives events when its section changes. - **Status conditions**: After handlers run, the leader writes `metav1.Condition` entries back to `.status.conditions` with conflict retry. - **Autodiscovery handler stub**: Skeleton handler that checks for `spec.config.checks` presence. Returns `ConditionUnknown` until check delivery is implemented in a follow-up. - **Registration**: Gated behind `datadog_instrumentation.enabled: true` in the Cluster Agent controller catalog. ### Motivation Part of the [DatadogInstrumentation CRD initiative](https://datadoghq.atlassian.net/wiki/spaces/CONTP/pages/6564659495/DatadogInstrumentation+CRD+for+Workload-Scoped+Product+Enablement) to enable workload-scoped product configuration through a Kubernetes-native CRD. This PR builds the shared controller platform that all product handlers (Autodiscovery check delivery, APM SSI, etc.) will plug into. Depends on: DataDog/datadog-operator#2962 ### Describe how you validated your changes Unit tests covering reconciliation dispatch, section-level event classification, leader-only status writes, `lastSeen` lifecycle, event deduplication, and status condition updates with a fake dynamic client. #### CR status is updated on each create/update/delete event <img width="696" height="173" alt="image" src="https://github.com/user-attachments/assets/37310f64-caf8-4167-b305-331a6ead76c9" /> <img width="793" height="610" alt="image" src="https://github.com/user-attachments/assets/5f884b70-a71e-4621-92b2-f5299fd62d68" /> Co-authored-by: mathew.estafanous <[email protected]>
…ent dispatching (#50206) ### What does this PR do? Introduces a `DatadogInstrumentation` CRD controller in the Cluster Agent that watches `DatadogInstrumentation` custom resources and dispatches section-level events (`EventCreate`, `EventUpdate`, `EventDelete`) to product-specific handlers. - **Controller** (`pkg/clusteragent/instrumentation/`): Uses a key-only workqueue with a `lastSeen` store to diff current state (from the informer cache) against the last successfully reconciled state. This gives natural deduplication and prevents stale-snapshot bugs on requeue. - **`Handler` interface**: Product handlers implement `HasSection`, `Handle`, `Validate`, and `SupportsTarget`. Each handler owns a section of the CR spec and only receives events when its section changes. - **Status conditions**: After handlers run, the leader writes `metav1.Condition` entries back to `.status.conditions` with conflict retry. - **Autodiscovery handler stub**: Skeleton handler that checks for `spec.config.checks` presence. Returns `ConditionUnknown` until check delivery is implemented in a follow-up. - **Registration**: Gated behind `datadog_instrumentation.enabled: true` in the Cluster Agent controller catalog. ### Motivation Part of the [DatadogInstrumentation CRD initiative](https://datadoghq.atlassian.net/wiki/spaces/CONTP/pages/6564659495/DatadogInstrumentation+CRD+for+Workload-Scoped+Product+Enablement) to enable workload-scoped product configuration through a Kubernetes-native CRD. This PR builds the shared controller platform that all product handlers (Autodiscovery check delivery, APM SSI, etc.) will plug into. Depends on: DataDog/datadog-operator#2962 ### Describe how you validated your changes Unit tests covering reconciliation dispatch, section-level event classification, leader-only status writes, `lastSeen` lifecycle, event deduplication, and status condition updates with a fake dynamic client. #### CR status is updated on each create/update/delete event <img width="696" height="173" alt="image" src="https://github.com/user-attachments/assets/37310f64-caf8-4167-b305-331a6ead76c9" /> <img width="793" height="610" alt="image" src="https://github.com/user-attachments/assets/5f884b70-a71e-4621-92b2-f5299fd62d68" /> Co-authored-by: mathew.estafanous <[email protected]>
What does this PR do?
Relates to #1605
Defines the operator-side
DatadogInstrumentationCRD indatadoghq.com/v1alpha1for future use by the Cluster Agent. This PR only publishes the API surface. It does not add an Operator reconciler or runtime controller logic.Example
Motivation
This CRD follows the Datadog Instrumentation RFC by defining a Kubernetes API object that the Cluster Agent can consume to apply workload instrumentation configuration.
The spec is intentionally scoped to Autodiscovery checks for now. It uses
spec.targetReffor workload targeting, requiresspec.config, keeps integration-specific check payloads flexible through rawinitConfigandinstances, and types the documented custom log collection fields while preserving unknown log fields for forward compatibility.Additional Notes
spec.configis required. Insidespec.config.checks,integrationis required for each check entry. Other check fields are optional.The log configuration schema includes the documented Datadog Agent custom log collection fields, while preserving unknown fields on each log item for forward compatibility with Agent-supported options.
Describe your test plan
Ran:
make generate make manifests go test ./api/... bin/darwin-arm64/operator-sdk bundle validate ./bundleAlso verified
make generate && make manifestsproduces no additional diff after generated files are up to date.Checklist
bug,enhancement,refactoring,documentation,tooling, and/ordependenciesqa/skip-qalabel