Add DRA DaemonSet reconciler

[TomerNewman]

Add DRA DaemonSet reconciler

Summary

Implements a DRAReconciler that manages DRA driver DaemonSets from Module.spec.dra, mirroring the DevicePluginReconciler pattern. Also improves the DevicePluginReconciler with role labeling, cleanup on spec.devicePlugin removal, and clearer naming.

Changes

• internal/constants/constants.go: Add DRARoleLabelValue = "dra" and DevicePluginRoleLabelValue = "device-plugin" constants
• internal/controllers/dra_reconciler.go: New DRA reconciler with helper and DaemonSet creator — creates DaemonSets with mandatory kubelet-plugins host-path volumes, DRA-specific container names, DaemonSetRole label, and status patching
• internal/controllers/dra_reconciler_test.go: Comprehensive unit tests covering all reconcile paths, helper methods, and DaemonSet spec generation
• internal/controllers/device_plugin_reconciler.go:
  • Fix getModuleDevicePluginDaemonSets to exclude DRA-labeled DaemonSets
  • Add DevicePluginRoleLabelValue label to device plugin DaemonSets (exclusion-based query kept for backward compat, with TODO(3.0) to switch)
  • Add cleanup logic when spec.devicePlugin is removed (delete DaemonSets + clear status)
  • Rename handleModuleDeletion → deleteDevicePluginDaemonSets for clarity
• internal/controllers/device_plugin_reconciler_test.go: Tests for DRA exclusion, spec.devicePlugin nil cleanup, clearDevicePluginStatus, and updated label expectations

Testing

• Unit tests: Full coverage of Reconcile (good flow, error flows, deletion, spec removal), handleDRA (create/update), deleteDRADaemonSets, moduleUpdateDRAStatus, clearDRAStatus, setDRAAsDesired (with/without init container, volumes, labels), getModuleDRADaemonSets, clearDevicePluginStatus, and device plugin nil cleanup paths
• Integration tests: N/A
• Coverage: 100% on all new behavioral functions

Acceptance Criteria

• AC-1: DRAReconciler watches Module and owns DaemonSet resources
• AC-2: Reconcile is a no-op when spec.dra == nil
• AC-3: DaemonSet is created with GenerateName: mod.Name + "-dra-"
• AC-4: DaemonSet auto-mounts kubelet-plugins and kubelet-plugins-registry host paths; user volumes appended after
• AC-5: Container names are dra-init (init) and dra (main)
• AC-6: DaemonSet pod labels include ModuleNameLabel, DaemonSetRole: DRARoleLabelValue
• AC-7: DaemonSet nodeSelector includes GetKernelModuleReadyNodeLabel(ns, name)
• AC-8: DaemonSet is updated when Module spec changes and deleted when spec.dra is removed or Module is deleted
• AC-9: status.dra is patched mirroring moduleUpdateDevicePluginStatus
• AC-10: Unit tests verify DaemonSet spec generation, early exit, create/update/delete paths, and status patching

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[netlify]

✅ Deploy Preview for kubernetes-sigs-kmm ready!

Name	Link
🔨 Latest commit	4f51daa
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-kmm/deploys/6a29415321b56e00089cc849
😎 Deploy Preview	https://deploy-preview-1283--kubernetes-sigs-kmm.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: TomerNewman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [TomerNewman]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[TomerNewman]

/cc @ybettan
/uncc @mresvanis
/assign @ybettan @yevgeny-shnaidman

[codecov-commenter]

Codecov Report

❌ Patch coverage is 90.11628% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.55%. Comparing base (fa23a9b) to head (4f51daa).
⚠️ Report is 378 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/controllers/dra_reconciler.go	90.19%	14 Missing and 1 partial ⚠️
internal/controllers/device_plugin_reconciler.go	89.47%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1283      +/-   ##
==========================================
- Coverage   79.09%   73.55%   -5.54%     
==========================================
  Files          51       67      +16     
  Lines        5109     4871     -238     
==========================================
- Hits         4041     3583     -458     
- Misses        882     1123     +241     
+ Partials      186      165      -21     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TomerNewman]

/uncc @mresvanis

[yevgeny-shnaidman]

what about adding Role label to the device plugin daemonset? This way you can add the Role label to opts := []client.ListOption{....}
and get the needed DS without afterwards going over the label.

[TomerNewman]

its not backward compatible, old DS will not be found after an upgrade

[yevgeny-shnaidman]

why does it matter? The code will run CreateOrPatch with the same name and namespace, and the DS will be updated accordingly, and will be re-found in the next loop. Is there something catch that i am missing?

[TomerNewman]

The DS is created with GenerateName, not a fixed name. So CreateOrPatch would create a new DS instead of updating the old one. The old DS would remain orphaned — never found by the query, never garbage collected.

[TomerNewman]

updating - we will add the label now but quarry like it was implemented before, when 3.0 release will come, we will quarry with this new label.

[yevgeny-shnaidman]

This function is used to delete DRA DS both when the Module is deleted, and when the Module is updated and its DRA field is set to nil. WDYT about renaming it to: deleteDRADaemonset, or something like that?

[TomerNewman]

I named it in puepose in order to be the same as we do it in DevicePlugin, but since you are right I renamed it both in DRA and in DevicePlugin controllers.

[yevgeny-shnaidman]

we should also add a code to the DevicePluginReconciler, that deletes the DevicePlugin DS in case device plugin is not set in Module (the same way as you do in DRA reconciler). This should cover the case where user switches between DRA and DevicePlugin

[yevgeny-shnaidman]

what about DeviceResource? Where will it be reconciled?

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: TomerNewman / name: TomerNewman (4f51daa)

[TomerNewman]

what about DeviceResource? Where will it be reconciled?

DeviceClass do you mean?

[yevgeny-shnaidman]

what about DeviceResource? Where will it be reconciled?

DeviceClass do you mean?

yes :)

[yevgeny-shnaidman]

i don't think we should see more then 1 DRA daemoset here. lets return the pointer to the DS, instead of slice

[yevgeny-shnaidman]

The same can implemented also for DevicePlugin

[TomerNewman]

Currently, DRA only creates a single DaemonSet per Module — you're right about that. However, the next phase of DRA work will add ordered upgrade support, mirroring DevicePlugin's existing mechanism. During ordered upgrades, two DRA DaemonSets will coexist (old version kept until DesiredNumberScheduled == 0, then garbage collected) — same as DevicePlugin does today via getExistingDSFromVersion + garbageCollect.

Keeping the slice now avoids refactoring it back when ordered upgrades are implemented. For the same reason, DevicePlugin should also stay as a slice — it already uses multiple DaemonSets during version transitions.

[yevgeny-shnaidman]

/lgtm