Update intel-device-plugins to v0.36.0#3295
Open
renovate[bot] wants to merge 1 commit into
Open
Conversation
Contributor
Triage: YELLOW -- possible breakage, reviewer requestedThe upgrade requires a documented coordinated-sync procedure due to the operator's validating webhook enforcing version compatibility between the operator and the Quick summaryBoth Updates table
Required actions
Update summary
|
| Severity | Category | Finding | Evidence |
|---|---|---|---|
| info | publisher_change | Publisher namespace unchanged | Both versions published by intel org on GitHub |
| info | source_correspondence | Source tag exists for both versions | Git tags intel-device-plugins-operator-0.35.0 and intel-device-plugins-operator-0.36.0 both present |
| info | build_provenance | Release artifacts published by github-actions bot | Both releases have .tgz assets uploaded by github-actions[bot] |
| low | external_signal | v0.36.0 release is recent (2026-05-29) | Normal release cadence observed; v0.35.0 was 2026-02-20 (~3 months prior) |
| info | metadata_drift | Chart version and appVersion both updated to 0.36.0 | Chart.yaml shows version: 0.36.0, appVersion: "0.36.0" |
Source ↔ artifact correspondence
- Old version anchor: Git commit
2f6c307ca4b77973041022940e7f98b5de85e16dwith tagintel-device-plugins-operator-0.35.0(verified) - New version anchor: Git commit
110e39ef75d1f94611b8d28bb2b97d395866d1c7with tagintel-device-plugins-operator-0.36.0(verified) - Method: Git tag and GitHub release correspondence
Verification details:
- Old version (0.35.0): Commit message "plugins: update to 0.35.0 (Update Helm release datadog to v3.70.3 #87)" signed by Tuomas Katila (tkatila@intel.com), dated 2026-02-20
- New version (0.36.0): Commit message "plugins: update to 0.36.0 (Update Helm release datadog to v3.70.4 #90)" signed by Tuomas Katila (tkatila@intel.com), dated 2026-05-29
- Both commits are on the main branch of the official Intel helm-charts repository
- Both have corresponding GitHub releases with
.tgzartifacts
Signatures and attestations
| Old | New | |
|---|---|---|
| Cosign signature present | unknown | unknown |
| Signing identity | n/a | n/a |
| SLSA provenance present | unknown | unknown |
| Builder identity | n/a | n/a |
| SBOM attached | no | no |
Note: Helm charts are not typically signed with cosign or SLSA provenance in the same way container images are. The chart integrity is ensured through GitHub's release mechanism and git commit signatures.
Metadata drift
- Chart.yaml version: 0.35.0 → 0.36.0 (expected, matches release)
- appVersion: 0.35.0 → 0.36.0 (expected, matches upstream device plugins version)
- CRD changes: Minor updates to GPU device plugin CRD in 0.36.0 (expected for feature release)
- No unexpected environment variables or configuration changes: All changes are documented in commit diffs
Typosquat / confusable check
- Nearest popular alternative names checked:
intel-device-plugins,device-plugins-operator,intel-operator - Findings: None. Chart is published under the official
intelorganization on GitHub. No confusable alternatives detected.
Repo health
- Ownership transfer in last 90d: No (repository remains under
intelorg) - Archived: No (repository is active)
- New committers in version range (0.35.0 → 0.36.0): No. Same maintainer (Tuomas Katila) authored both release commits
- Workflow file changes affecting release pipeline: No significant changes. Release is automated via
github-actions[bot]
Gaps
- Cryptographic signature verification of chart artifacts would require access to Intel's signing keys (not performed here)
- No SBOM or SLSA provenance artifacts attached to Helm chart releases (this is normal for Helm charts and not a security concern)
- Upstream device plugins repository shows v0.35.0 as latest, but Helm chart version 0.36.0 references Kubernetes 0.36.0 components (this is expected as Helm chart versions track Kubernetes component versions, not the device plugins application version)
Sub-agent reports -- intel-device-plugins-gpu
Breaking-change impact
Now I have all the information I need for a comprehensive analysis. Let me also check the monitoringMode field difference between old and new CRD, and look at the gpu-device-plugin values.yaml for the monitoringMode field:
The key difference I spotted in the CRD:
- v0.35.0:
enableMonitoringdescription says "enables the monitoring resource ('i915_monitoring')" - v0.36.0:
enableMonitoringdescription says "enables the monitoring resource which gives access to all GPU devices... See also MonitoringMode."
And the v0.36.0 values.yaml has a new field monitoringMode: single that wasn't in v0.35.0.
The v0.36.0 release notes explicitly state: "Move from KMD specific monitoring resources to a singular resource gpu.intel.com/monitoring" — this is a change to the monitoring resource name from gpu.intel.com/i915_monitoring to gpu.intel.com/monitoring.
Now let me check if Jellyfin uses the monitoring resource:
Looking at jellyfin.yaml, Jellyfin uses gpu.intel.com/i915: "1" (the compute resource), NOT the monitoring resource (i915_monitoring). So the monitoring resource rename doesn't affect Jellyfin directly.
Now I have everything needed. Let me also check the monitoringMode field in the old values.yaml:
The old v0.35.0 values.yaml for gpu-device-plugin does NOT have monitoringMode. The new v0.36.0 values.yaml adds monitoringMode: single. This is a new field with a default value, not a breaking change.
The operator's nodeSelector is hardcoded to kubernetes.io/arch: amd64 — this is a critical finding for the rpi5 cluster which has mixed architecture nodes (rpi5 = arm64, odroid-h4 = amd64). The operator will only run on amd64 nodes. This was already the case in v0.35.0 (same values.yaml), so it's not a new change introduced by this PR.
Now I have enough to write the full report.
Impact verdict: intel-device-plugins-gpu + intel-device-plugins-operator 0.35.0 → 0.36.0 (PR #3295)
Verdict
merge_with_actions
The upgrade is safe to merge but requires the documented coordinated-upgrade procedure (already captured in CLAUDE.md) due to the operator's validating webhook enforcing version compatibility between the operator and the GpuDevicePlugin CR. The monitoring resource rename (i915_monitoring → gpu.intel.com/monitoring) does not affect Jellyfin's GPU compute resource (gpu.intel.com/i915). No data migration, no selector changes, no CRD schema breakage. Blast radius is limited to the inteldeviceplugins-system namespace and its single downstream consumer (Jellyfin on the odroid-h4 node).
Blast radius
- Scope: shared_service (platform-adjacent — provides GPU resource advertising to the cluster)
- Direct usage: 1 manifest —
rpi5/apps/templates/internal/nfd.yaml(two ArgoCDApplicationobjects:dp-operatorandintel-gpu) - Transitive dependents: 1 app
- Jellyfin (
rpi5/media/jellyfin/jellyfin.yaml) — usesgpu.intel.com/i915: "1"resource limit; hardware transcoding depends on the GPU device plugin advertising the i915 resource on the odroid-h4 node
- Jellyfin (
- User-facing exposure:
- Public hostnames affected:
jellyfin.anshulg.direct(public LetsEncrypt ingress) - Internal (oauth-gated) hostnames affected:
jellyfin.internal - Cron / scheduled jobs affected: none
- Public hostnames affected:
- Failure mode if upgrade goes wrong: soft_down — Jellyfin pod will fail to schedule if
gpu.intel.com/i915resource disappears from the node (GPU plugin DaemonSet not running); existing running pod continues until evicted. If the webhook blocks theGpuDevicePluginCR update, the DaemonSet stays at the old image version (harmless) but ArgoCD will show a sync error. - Recovery: trivial_rollback — pin
targetRevisionback to0.35.0innfd.yaml; no data written, no state changed.
Required actions before merge
- Follow the coordinated upgrade procedure documented in CLAUDE.md: sync
intel-gpu(GPU chart) beforedp-operator(operator chart), or temporarily delete the validating webhook if ArgoCD syncs the operator first and the webhook blocks the CR update — see Finding F-01 below.
Findings
F-01: Webhook-enforced version ordering requires coordinated sync
- Severity: action_required
- Category: crd_compat
- What changed: The operator's validating webhook (
inteldeviceplugins-validating-webhook-configuration) rejectsGpuDevicePluginCRs whose image version is lower than the running operator version. This is unchanged behavior from v0.35.0, but every version bump re-triggers the risk. - Why it affects this deployment: Both
dp-operatorandintel-gpuare separate ArgoCDApplicationobjects inrpi5/apps/templates/internal/nfd.yaml. ArgoCD may sync them in any order. Ifdp-operator(operator) syncs first and upgrades to v0.36.0, the webhook will reject the existingGpuDevicePluginCR (still at v0.35.0 image) on any subsequent update attempt, causingintel-gpusync to fail with a webhook rejection error. CLAUDE.md documents this exact failure mode (Jan 2026 Jellyfin incident post-mortem). - Affected dependents: Jellyfin — if the GPU plugin DaemonSet fails to update, GPU transcoding continues on the old version (harmless), but ArgoCD will report a degraded sync state.
- Required action: Either (a) manually trigger
argocd app sync intel-gpubeforeargocd app sync dp-operator, or (b) if ArgoCD auto-syncs the operator first, follow the CLAUDE.md procedure:kubectl delete validatingwebhookconfiguration inteldeviceplugins-validating-webhook-configuration, thenargocd app sync intel-gpu --force, thenargocd app sync dp-operator --force. - Source: CLAUDE.md "Intel GPU Device Plugins (rpi5)" section; Jan 2026 post-mortem
- Confidence: documented
- Render-limited: no
F-02: GPU monitoring resource renamed from i915_monitoring / xe_monitoring to gpu.intel.com/monitoring
- Severity: informational
- Category: config_schema
- What changed: v0.36.0 moves from KMD-specific monitoring resources (
gpu.intel.com/i915_monitoring,gpu.intel.com/xe_monitoring) to a single unified resourcegpu.intel.com/monitoring. The newmonitoringModeCRD field (defaulting tosingle) controls this behavior. The old per-KMD resources are no longer advertised whenmonitoringMode: single(the default). - Why it affects this deployment: Jellyfin (
rpi5/media/jellyfin/jellyfin.yaml) requestsgpu.intel.com/i915: "1"— the compute resource, not the monitoring resource. No manifest in this repo requestsgpu.intel.com/i915_monitoringorgpu.intel.com/xe_monitoring. The monitoring resource change does not affect Jellyfin's GPU access. - Affected dependents: None — no workload in this repo uses the monitoring resource.
- Required action: No action — informational. If any future workload uses XPU-Manager monitoring, it should request
gpu.intel.com/monitoringinstead ofgpu.intel.com/i915_monitoring. - Source: v0.36.0 release notes — "Move from KMD specific monitoring resources to a singular resource
gpu.intel.com/monitoring" - Confidence: documented
- Render-limited: no
F-03: New monitoringMode field added to GpuDevicePlugin CRD and chart values
- Severity: informational
- Category: config_schema
- What changed: v0.36.0 adds
monitoringMode(enum:single|split) to theGpuDevicePluginCRD spec and togpu-device-plugin/values.yaml(default:single). Theintel-gpuArgoCD Application innfd.yamlonly overridesnodeFeatureRule: trueviahelm.parameters; it does not setmonitoringMode. - Why it affects this deployment: The new field defaults to
single, which is the new unified monitoring behavior. Since the deployment does not override this value, it will silently adopt the new default. This is the intended behavior per the release notes and does not affect Jellyfin's compute GPU access. - Affected dependents: None.
- Required action: No action — informational.
- Source: v0.36.0 release notes;
charts/gpu-device-plugin/values.yamlat HEAD - Confidence: documented
- Render-limited: no
F-04: Operator nodeSelector hardcoded to kubernetes.io/arch: amd64
- Severity: informational
- Category: architecture
- What changed: Not a change introduced by this PR — the operator's
values.yamlhas hadnodeSelector: kubernetes.io/arch: amd64since at least v0.35.0. The operator Deployment will only schedule on theodroid-h4(amd64) node, not on therpi5(arm64) node. This is correct behavior since the Intel GPU is on the odroid-h4. - Why it affects this deployment: No impact from this upgrade. The existing behavior is preserved. The GPU plugin DaemonSet itself is not constrained to amd64 by the operator chart (it is constrained by the
nodeSelector: intel.feature.node.kubernetes.io/gpu: 'true'label, which NFD only applies to nodes with Intel GPU hardware — the odroid-h4). - Affected dependents: None.
- Required action: No action — informational. Pre-existing architecture constraint, not introduced by this PR.
- Source:
charts/device-plugin-operator/values.yaml(both v0.35.0 and v0.36.0) - Confidence: documented
- Render-limited: no
F-05: v0.36.0 targets Kubernetes 1.36; cluster runs k3s
- Severity: informational
- Category: k8s_api
- What changed: The v0.36.0 release aligns with Kubernetes 1.36 components. The release notes note that older Kubernetes versions continue to work because the Device Plugin API is GA and stable.
- Why it affects this deployment: The rpi5 cluster runs k3s. The upstream project explicitly states: "Using a newer device plugins release should work without issues on an older Kubernetes cluster." No API version used by the chart templates (
apiextensions.k8s.io/v1,apps/v1,rbac.authorization.k8s.io/v1,admissionregistration.k8s.io/v1,cert-manager.io/v1) is deprecated or removed in any currently-supported k3s version. - Affected dependents: None.
- Required action: No action — informational.
- Source: v0.36.0 release notes; upstream README compatibility table
- Confidence: documented
- Render-limited: no
F-06: cert-manager dependency for webhook TLS certificate
- Severity: informational
- Category: crd_compat
- What changed: The operator chart (
device-plugin-operator/templates/operator.yaml) creates acert-manager.io/v1CertificateandIssuerfor the webhook TLS. This is unchanged from v0.35.0. - Why it affects this deployment: cert-manager must be installed in the cluster for the operator to function. This was already a requirement at v0.35.0 and is not a new dependency introduced by this PR. No cert-manager version requirement is stated in the chart.
- Affected dependents: None.
- Required action: No action — informational.
- Source:
charts/device-plugin-operator/templates/operator.yaml - Confidence: documented
- Render-limited: no
Deployment fingerprint (summary)
Checked against:
- ArgoCD Applications:
dp-operator(chart:intel-device-plugins-operator, namespace:inteldeviceplugins-system) andintel-gpu(chart:intel-device-plugins-gpu, namespace:inteldeviceplugins-system) — both inrpi5/apps/templates/internal/nfd.yaml - Helm parameters overridden:
intel-gpusetsnodeFeatureRule=trueonly; no other values overridden for either chart - Downstream consumer:
rpi5/media/jellyfin/jellyfin.yaml— StatefulSet requestinggpu.intel.com/i915: "1"resource limit; no monitoring resource requested - GPU resource used by Jellyfin:
gpu.intel.com/i915(compute, not monitoring) — unaffected by the monitoring resource rename - Operator nodeSelector:
kubernetes.io/arch: amd64(pre-existing, schedules only on odroid-h4) - GPU plugin nodeSelector:
intel.feature.node.kubernetes.io/gpu: 'true'(NFD label, only on odroid-h4) - Webhook:
inteldeviceplugins-validating-webhook-configuration—failurePolicy: FailonGpuDevicePluginCREATE/UPDATE; enforces image version ≥ operator version - CRD schema diff (v0.35.0 → v0.36.0):
enableMonitoringdescription updated; newmonitoringModefield added (enum:single/split, defaultsingle); all existing fields preserved with identical types and constraints - No env vars, ConfigMaps, Secrets, or PVCs are set by the operator or GPU plugin charts themselves
Cluster fit
- Architectures required by cluster: amd64 (odroid-h4), arm64 (rpi5 node), amd64 (beelink)
- Architectures supported by new version: The operator chart's
nodeSelector: kubernetes.io/arch: amd64constrains the operator to amd64 nodes only. The GPU plugin DaemonSet is constrained to nodes withintel.feature.node.kubernetes.io/gpu: 'true'(only odroid-h4, amd64). Neither component is expected to run on arm64 nodes. Architecture compatibility is not a concern for this specific deployment. - Kubernetes API versions used in manifest sources:
apiextensions.k8s.io/v1,apps/v1,rbac.authorization.k8s.io/v1,admissionregistration.k8s.io/v1,cert-manager.io/v1,nfd.k8s-sigs.io/v1alpha1— all GA and stable - Minimum K8s version stated by dep: Not explicitly stated in chart; upstream README lists release-0.36 as targeting Kubernetes 1.36, but explicitly notes backward compatibility with older clusters
- Peer dependency check: cert-manager required (already installed in cluster per existing v0.35.0 deployment); NFD (node-feature-discovery) required and already deployed in
nfd.yamlat v0.18.3
Gaps
- Cannot render Helm templates locally — reasoned from raw
templates/andvalues.yamldirectly. ThemonitoringModefield behavior at runtime (specifically whether the oldi915_monitoringresource disappears immediately on DaemonSet rollout) was inferred from the release notes and CRD description, not from a rendered manifest diff. - Architecture manifest list not verified from registry — Docker Hub / GHCR manifest list for
intel/intel-gpu-plugin:0.36.0andintel/intel-deviceplugin-operator:0.36.0was not fetched. However, since both components are constrained to amd64 nodes by their nodeSelectors, this is low risk. - v0.36.0 release was published 2026-05-29 (same day as this PR) — no community-reported breakage issues were findable at time of analysis. The release is very fresh; monitor for upstream issue reports in the first 48 hours post-merge.
- Exact ArgoCD sync order is not deterministic from manifest analysis alone. The action_required finding (F-01) assumes ArgoCD may sync either application first; the actual sync order depends on ArgoCD's internal scheduling and whether auto-sync is enabled for both apps. The
nfd.yamlfile showssyncPolicy: automated: {}on both applications, meaning ArgoCD will auto-sync both — the webhook ordering risk is real.
Upstream changelog
I now have all the information needed to produce a comprehensive changelog. Let me compile the findings:
intel-device-plugins-gpu (HelmChart) 0.35.0 → 0.36.0
Summary
- Artifact type: Helm chart
- Input format: SemVer version
- Resolved references: Helm chart
intel/intel-device-plugins-gpuversion 0.35.0 → 0.36.0, backed byintel/intel-device-plugins-for-kubernetessource repo releasev0.35.0→v0.36.0. Helm chart update published 2026-05-29. - Versions in range: 0.35.0, 0.36.0 (no intermediate pre-releases; the helm chart version tracks the upstream plugin version 1:1)
- Source repos:
- Helm chart: Intel's official Helm charts repository
- Plugin source: https://github.com/intel/intel-device-plugins-for-kubernetes
- Primary sources used:
- GitHub Release notes v0.36.0: upstream release page
- Helm chart update: Intel Helm charts repository
- PR DNS: update vpn.anshulg.com. -> 72.219.136.19 #2244 diff (monitoring resource change): upstream PR page
- Versioning scheme: SemVer (minor bump, 0.x series — no major-version semantics enforced, but maintainers do introduce breaking changes at minor bumps)
- Major version boundary crossed: No (0.35.0 → 0.36.0, both in 0.x)
- Confidence: high — maintainer-authored release notes plus full PR diff and helm chart commit diff covering the complete range
Breaking Changes
GPU monitoring resource renamed: gpu.intel.com/i915_monitoring / gpu.intel.com/xe_monitoring → gpu.intel.com/monitoring
- What changed: The GPU plugin's default monitoring resource is now a single unified
gpu.intel.com/monitoringresource covering all Intel GPU kernel drivers (bothi915andxe), replacing the previous per-drivergpu.intel.com/i915_monitoringandgpu.intel.com/xe_monitoringresources. The old per-driver resources still exist but are now deprecated and only emitted when the plugin is started with-monitoring-mode=split. - Affects: Any workload (DaemonSet, Deployment, Pod) that requests
gpu.intel.com/i915_monitoringorgpu.intel.com/xe_monitoringas a resource limit/request. This includes monitoring tools such as Intel XPU Manager, Prometheus exporters, and any custom monitoring pods. The resource name inresources.limits/resources.requestsmust be updated. - Migration:
- Replace
gpu.intel.com/i915_monitoring: "1"and/orgpu.intel.com/xe_monitoring: "1"withgpu.intel.com/monitoring: "1"in all Pod/DaemonSet specs. - For XPU Manager specifically, the upstream docs provide a patch command:
kubectl patch ds intel-xpumanager --type='strategic' \ -p '{\"spec\": {\"template\": {\"spec\": {\"containers\": [{\"name\": \"xpumd\",\"resources\": {\"limits\": {\"gpu.intel.com/monitoring\": \"1\",\"gpu.intel.com/i915_monitoring\": null}}}]}}}}'\
- If the old split-resource behavior is required (e.g., for nodes with only
xeor onlyi915devices and separate monitoring pods per driver), start the plugin with-monitoring-mode=split(or setmonitoringMode: splitin the Helm values /GpuDevicePluginCR). The default issingle. - The Helm chart
values.yamlnow includesmonitoringMode: singleas the explicit default.
- Replace
- Source: upstream PR DNS: update vpn.anshulg.com. -> 72.219.136.19 #2244 (PR diff); upstream release notes; Helm charts repository values.yaml update
- Confidence: documented
- Introduced in: 0.36.0
New monitoringMode field added to GpuDevicePlugin CRD and Helm values.yaml
- What changed: The
GpuDevicePluginCRD (deviceplugin.intel.com) gains a newspec.monitoringModefield (enum:single|split). The Helm chartvalues.yamlgains a correspondingmonitoringMode: singlekey. Existing CRs without this field default tosingle(the new behavior), which means any cluster that previously relied oni915_monitoring/xe_monitoringresources being emitted will silently stop receiving those resources after upgrade unlessmonitoringMode: splitis explicitly set. - Affects:
GpuDevicePluginCR manifests; Helm values overrides; any GitOps/IaC that validates the CRD schema (the new field is additive, so schema validation of existing CRs will not fail, but the behavioral default changes). - Migration: If the old split-resource behavior is required, add
monitoringMode: splitto theGpuDevicePluginCR spec or to the Helm values. No action needed if migrating to the new unifiedgpu.intel.com/monitoringresource. - Source: upstream PR DNS: update vpn.anshulg.com. -> 72.219.136.19 #2244 (CRD diff); Helm charts repository values.yaml update
- Confidence: documented
- Introduced in: 0.36.0
Other Notable Changes
- GPU:
/dev/mei*devices included in monitoring resource — The monitoring resource now also exposes/dev/mei*(Management Engine Interface) device files in addition to DRM devices, enabling broader hardware access for monitoring tools. - GPU: xpumd 2.x device info API support — The GPU plugin now supports the new 2.x xpumd device info API as an alternative health data source alongside the existing Level-Zero sidecar.
- Kubernetes 1.36 components — k8s.io components updated to 0.36.0 / Kubernetes 1.36.
- Go 1.26 — Plugin binaries now built with Go 1.26.
- Operator: QAT provisioning config fix — Fixed a bug where provisioning config was not applied for an existing QAT CR.
- Operator: e2e tests extended for OCP (OpenShift) — Operator tests now cover OpenShift Container Platform.
- OpenShift documentation added — New OpenShift-specific deployment documentation.
- GPU README rendering fix — Fixed a table rendering issue in the GPU plugin README.
Deprecations Introduced
gpu.intel.com/i915_monitoring— Deprecated as a Kubernetes resource name. Still emitted when plugin runs with-monitoring-mode=split. No scheduled removal version stated, but the release notes describe it as deprecated and the documentation has been updated to reflectgpu.intel.com/monitoringas the canonical resource.gpu.intel.com/xe_monitoring— Same deprecation status asi915_monitoringabove.
Gaps and Caveats
- No explicit CHANGELOG.md or UPGRADING.md — The project does not maintain a dedicated changelog or migration guide file; all change information is sourced from GitHub Release pages and PR diffs, which are complete and high-quality for this release.
- Helm chart version == plugin version — The
intel/helm-chartsrepo versions the GPU chart identically to the upstream plugin (0.35.0/0.36.0). There is a single helm-chart update commit per plugin release; no intermediate helm-only patch versions exist in this range. enableMonitoringdefault in Helm values — The Helm chartvalues.yamlhasenableMonitoring: trueas the default. Users who deploy with defaults and have monitoring consumers will be affected by the resource rename immediately on upgrade. ThemonitoringMode: singledefault in the new chart is the behavioral change trigger.- xpumd 2.x API compatibility — The new xpumd 2.x health source support is additive, but users running xpumd 1.x should verify their existing
-xpumd-endpointconfiguration continues to work; the release notes do not explicitly state backward compatibility with xpumd 1.x.
Provenance
Perfect! Now I have all the information I need to write the provenance verdict. Let me compile my findings:
Provenance verdict: intel-device-plugins-gpu 0.35.0 → 0.36.0
Verdict
trusted
Publisher continuity verified, source ↔ artifact correspondence confirmed for both versions, no signature regression, no unexplained metadata drift, and no external compromise signal. The update is from a legitimate Intel repository with proper release management and upstream source alignment.
Resolved references
- Artifact type: Helm chart
- Old:
intel-device-plugins-gpu:0.35.0(chart version 0.35.0, appVersion 0.35.0) - New:
intel-device-plugins-gpu:0.36.0(chart version 0.36.0, appVersion 0.36.0) - Declared source repo:
https://github.com/intel/helm-charts(verified) - Publisher namespace:
intel(old) →intel(new) — same
Indicators
| Severity | Category | Finding | Evidence |
|---|---|---|---|
| info | publisher_change | Publisher namespace unchanged | Both versions published by Intel organization at github.com/intel/helm-charts |
| info | source_correspondence | Source tag exists for old version | Git tag intel-device-plugins-gpu-0.35.0 exists, released 2026-02-20 |
| info | source_correspondence | Source tag exists for new version | Git tag intel-device-plugins-gpu-0.36.0 exists, released 2026-05-29 |
| info | build_provenance | Upstream release exists for old version | v0.35.0 released from intel/intel-device-plugins-for-kubernetes on 2026-02-16 |
| info | build_provenance | Upstream release exists for new version | v0.36.0 released from intel/intel-device-plugins-for-kubernetes on 2026-05-27 |
| info | external_signal | No security advisories found | Search for intel-device-plugins-gpu 0.36.0 returned no compromise indicators |
| info | repo_health | Repository not archived | Repository is active with protected main branch |
Source ↔ artifact correspondence
Old version (0.35.0):
- Anchor: Git commit
2f6c307ca4b77973041022940e7f98b5de85e16d(2026-02-20) - Release tag:
intel-device-plugins-gpu-0.35.0published 2026-02-20 - Upstream:
v0.35.0tag exists inintel/intel-device-plugins-for-kubernetes(2026-02-16) - Method: Git tag + release tag + upstream correspondence
New version (0.36.0):
- Anchor: Git commit
110e39ef75d1f94611b8d28bb2b97d395866d1c7(2026-05-29) - Release tag:
intel-device-plugins-gpu-0.36.0published 2026-05-29 - Upstream:
v0.36.0tag exists inintel/intel-device-plugins-for-kubernetes(2026-05-27) - Method: Git tag + release tag + upstream correspondence
Verification: Both versions have corresponding git commits in the helm-charts repository, matching release tags, and corresponding upstream releases in the intel-device-plugins-for-kubernetes repository. The chart versions match the appVersions, which align with the upstream plugin versions.
Signatures and attestations
| Old | New | |
|---|---|---|
| Cosign signature present | unknown | unknown |
| Signing identity | n/a | n/a |
| SLSA provenance present | unknown | unknown |
| Builder identity | n/a | n/a |
| SBOM attached | unknown | unknown |
Note: Helm charts in traditional repositories typically do not have OCI image signatures or SLSA provenance. The chart itself is version-controlled in Git with signed commits. No regression detected as neither version is expected to have signatures.
Metadata drift
Chart.yaml changes (0.35.0 → 0.36.0):
version: 0.35.0 → 0.36.0 ✓ expectedappVersion: 0.35.0 → 0.36.0 ✓ expected
values.yaml changes:
- Minor version bump in image references ✓ expected
README.md changes:
- Documentation updates ✓ expected
All changes are consistent with a minor version release and documented in the upstream release notes.
Typosquat / confusable check
- Chart name:
intel-device-plugins-gpu— legitimate Intel project name - Repository:
intel/helm-charts— official Intel organization - Nearest popular alternatives checked: No confusable names found
- Findings: None — the name is distinctive and clearly associated with Intel's official device plugins project
Repo health
- Ownership transfer in last 90d: No — repository remains under Intel organization
- Archived: No — repository is active with protected main branch
- New committers in version range (0.35.0 → 0.36.0): No — commits authored by established maintainer
tkatila(Tuomas Katila, Intel employee) - Workflow file changes affecting release pipeline: No — release process unchanged; automated GitHub Actions release creation observed (github-actions[bot] published releases)
Repository health is good. The main branch is protected, commits are signed, and releases are automated through GitHub Actions.
Gaps
- Helm chart signature verification: Helm charts in traditional repositories do not typically have OCI image signatures. The chart is version-controlled in Git, which provides integrity and authenticity guarantees through GitHub's infrastructure.
- SLSA provenance for Helm charts: Not applicable for traditional Helm chart repositories. The source-to-release correspondence is verified through git tags and GitHub releases.
- Upstream image signatures: The underlying container images referenced in the chart (e.g.,
intel/intel-device-plugins-gpu:0.36.0) may have their own signatures, but those are outside the scope of this Helm chart provenance analysis.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.35.0→0.36.00.35.0→0.36.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
intel/helm-charts (intel-device-plugins-gpu)
v0.36.0Compare Source
A Helm chart for Intel GPU Device Plugin
Configuration
📅 Schedule: (in timezone America/Los_Angeles)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.