[Feature]: Wire `--system-node-selector` for slinky-slurm-operator once upstream PR #187 lands

[faganihajizada]

Prerequisites

• I searched existing issues

Summary

The slinky-slurm-operator component does not honor AICR's --system-node-selector flag because the upstream Slinky chart v1.1.0 silently ignores operator.nodeSelector and webhook.nodeSelector. Once SlinkyProject/slurm-operator#187 merges and a new chart version is published, AICR can wire the nodeSelector paths and bump the chart pin.

Background

Reproduction with slurm-operator chart v1.1.0:

helm pull oci://ghcr.io/slinkyproject/charts/slurm-operator --version 1.1.0
helm template slinky-slurm-op slurm-operator-1.1.0.tgz \
  --set operator.nodeSelector.foo=bar \
  --set webhook.nodeSelector.baz=qux | grep nodeSelector
# (no output — value silently discarded; chart templates only render
#  operator.{affinity,tolerations} and webhook.{affinity,tolerations})

This causes AICR's --system-node-selector flag to be a no-op for this component until upstream adds the templating. The current registry comment (recipes/registry.yaml under slinky-slurm-operator > nodeScheduling > system) documents the limitation, links the upstream PR, and includes the verbatim follow-up action.

Action items (once SlinkyProject/slurm-operator#187 merges and ships)

1. Bump recipes/registry.yaml slinky-slurm-operator > helm > defaultVersion from "1.1.0" to the chart version that includes Expose nodeSelector for operator and webhook SlinkyProject/slurm-operator#187.
2. In the same entry under nodeScheduling > system, add:

   nodeSelectorPaths:
     - operator.nodeSelector
     - webhook.nodeSelector

3. Remove the # Setting operator.nodeSelector / webhook.nodeSelector is silently dropped... comment block (it becomes obsolete).
4. Verify against a live cluster:

   make check-health COMPONENT=slinky-slurm-operator
   aicr bundle ... --system-node-selector key=value
   helm template <bundled-chart-path>/slinky-slurm-operator | grep -A2 nodeSelector
   # expect: operator and webhook deployments both carry the nodeSelector

Verification

• make qualify — must pass.
• Live smoke: install slurm-operator on a Kind cluster with --set operator.nodeSelector.kubernetes.io/os=linux, confirm the deployment carries the selector.

Problem/Use Case

AICR Slinky slurm-operator

Proposed Solution

Track SlinkyProject/slurm-operator#187 and apply changes to AICR when it lands

Success Criteria

Apply changes to AICR when SlinkyProject/slurm-operator#187 lands

Alternatives Considered

No response

Component

New component

Priority

Important (would improve my workflow)

Compatibility / Breaking Changes

No response

Operational Considerations

No response

Are you willing to contribute?

Yes, I can open a PR

[github-actions]

Welcome to AICR, @faganihajizada! Thanks for opening your first issue.

A maintainer will triage this shortly. In the meantime:

• Check the Contributing Guide for project conventions
• Browse existing labels for related topics
• Join the conversation in Discussions for questions

[mchmarny]

Triaged: Ready → Backlog. Work is blocked on upstream SlinkyProject/slurm-operator#187 merging and a new chart version publishing before AICR can wire operator.nodeSelector / webhook.nodeSelector and bump the chart pin. Returns to Ready once the upstream chart ships.

[mchmarny]

Triaged: Ready→Backlog. Hard-blocked on upstream SlinkyProject/slurm-operator#187 merging and a new slurm-operator chart release before AICR can wire the nodeSelector paths. Not actionable until then — moving to Backlog to keep Ready free of blocked work.

[faganihajizada]

Released as part of https://github.com/SlinkyProject/slurm-operator/commits/release-1.2/

I will work on this