Extend introspection and support DDAI code path#3108
Conversation
🛑 Gate Violations
ℹ️ Info🎯 Code Coverage (details) Useful? React with 👍 / 👎 This comment will be updated automatically if new data arrives.🔗 Commit SHA: eb26997 | Docs | Datadog PR Page | Give us feedback! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 74e241e65d
ℹ️ 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".
Codecov Report❌ Patch coverage is ❌ Your patch status has failed because the patch coverage (64.03%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #3108 +/- ##
==========================================
+ Coverage 44.03% 44.18% +0.14%
==========================================
Files 377 378 +1
Lines 30713 30903 +190
==========================================
+ Hits 13525 13654 +129
- Misses 16300 16352 +52
- Partials 888 897 +9
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
| case kubernetes.IsSpecificProvider(provider): | ||
| reason = clusterProviderReasonDetected |
There was a problem hiding this comment.
Why isn't source == clusterProviderSourceDetected used here to determine the reason?
There was a problem hiding this comment.
First case is clusterProviderSourceUser, which effectively leaves only clusterProviderSourceDetected. Added the conditional in a77b92b regardless to make it more obvious.
| if wasProviderDetected(instance) && kubernetes.IsSpecificProvider(statusProvider) && !kubernetes.IsSpecificProvider(live) { | ||
| return statusProvider, clusterProviderSourceDetected, false | ||
| } |
There was a problem hiding this comment.
❓ Is it possible for the new live detection to be persistent and not a 'blip?' Say a GKE cluster going from entirely GKE COS nodes to regular ubuntu. If so, wouldn't this gate always choose the status provider over live?
There was a problem hiding this comment.
It was possible as you pointed out with COS example, however this change should only handle cluster/global provider (EKS, Openshift, etc.) user cases. Intention here is correct, once cluster level provider detected, it can't shouldn't become empty, if we detect we are on EKS node label changes shouldn't revert that. Only way to override this is user provided annotation.
Made fix in a77b92b provider.go to separate cluster and node level provider detection.
| // Stage 1 — opportunistic keyed read of the operator's own node. | ||
| if d.nodeName != "" { | ||
| node := &corev1.Node{} | ||
| if err := d.apiReader.Get(ctx, types.NamespacedName{Name: d.nodeName}, node); err != nil { | ||
| d.logger.V(1).Info("operator-node provider read failed; trying cluster-node-list fallback", "node", d.nodeName, "error", err) |
There was a problem hiding this comment.
❓ Looking at this detection logic, is it possible the node that the operator is running on doesn't tell the full picture? Say on a GKE cluster that has both COS and ubuntu nodes. Depending on where the operator lands, it will 'detect' something different.
There was a problem hiding this comment.
this should be answered in the above comment; in this PR we only care global/cluster level changes for use cases like control plane monitoring for EKS and Openshift, autopilot.
Mathew-Estafanous
left a comment
There was a problem hiding this comment.
provider introspection look good
tbavelier
left a comment
There was a problem hiding this comment.
LGTM overall, but two points:
- This turns introspection "on" by default while it was previously opt-in: this is what we want, but should be called out. It is not immediately clear that introspection can be disabled using
datadoghq.com/provider: ""annotation on DDA - As a follow-up to the previous point and that one is why I'm "requesting changes", this breaks OpenShift users that did not have introspection before as we enable control-plane monitoring which mounts a secret in the Agent daemonset, however, this secret needs to be manually copied over (we log the command to run).
With the second point in mind, considering the operator has cluster-wide secrets access, I'm proposing as part of the control-plane monitoring feature for OpenShift to do this operation for users: #3131 so that way we don't break them and they start benefiting from it automatically. My approach is not perfect, it has tradeoffs (direct api read (not a write) every reconciliation to avoid the error below), I'm open to alternatives (e.g. add this namespace in bundles that we deploy on OpenShift / do something else)
{"level":"INFO","ts":"2026-06-12T09:46:10.796Z","logger":"controllers.DatadogAgentInternal","msg":"Unable to copy OpenShift etcd metric client secret automatically","namespace":"system","name":"datadog","reconcileID":"dd20b327-ef67-45a2-88f4-91e849090cf0","kind":"DatadogAgentInternal","namespace":"openshift-etcd-operator","name":"etcd-metric-client","error":"unable to get: openshift-etcd-operator/etcd-metric-client because of unknown namespace for the cache"}* copy OpenShift etcd metric secret * Add 5s timeout * Keep existing secret if source read fails
tbavelier
left a comment
There was a problem hiding this comment.
Conflict with main to resolve, but LGTM!
* Avoid agent getting stuck in container creating * Do not use direct apireader client and instead make f.etcdSecretPresent as part of existing calls (#3180) --------- Co-authored-by: Timothée Bavelier <[email protected]>
What does this PR do?
CONTP-1577
Change extends introspection detection mechanism to allow OOTB support for control plane monitoring on EKS (non-auto) and Openshift.
Change summary:
datadoghq.com/providerannotation.Motivation
Since 1.24 users had to disable DDAI code path to use OOTB control plane monitoring, since 1.27 this option isn't available. In addition users needed to set
introspectionEnabledflag for caching nodes for List operation. This change resolves former and make latter optional.Additional Notes
Anything else we should know when reviewing?
Minimum Agent Versions
Are there minimum versions of the Datadog Agent and/or Cluster Agent required?
Describe your test plan
kube_apiserver.*,kube_scheduler.*appear in the app.Checklist
bug,enhancement,refactoring,documentation,tooling, and/ordependenciesqa/skip-qalabel