Expose nodeSelector for operator and webhook#187
Closed
faganihajizada wants to merge 1 commit into
Closed
Conversation
a6377ed to
80f542c
Compare
The slurm-operator Helm chart did not document or wire `nodeSelector` for either the operator or webhook Deployment. Helm parsed values such as `--set operator.nodeSelector.foo=bar` into `.Values` without complaint and silently dropped them at render time, since no template referenced them and the chart has no `values.schema.json` to validate against. Changelog: Added - Helm chart fields `operator.nodeSelector` and `webhook.nodeSelector` for `slurm-operator`, mirroring the existing `affinity` and `tolerations` fields. Signed-off-by: Fagani Hajizada <[email protected]>
80f542c to
fedad2c
Compare
25 tasks
faganihajizada
added a commit
to faganihajizada/aicr
that referenced
this pull request
May 13, 2026
…slurm Adds the Slinky Slurm operator (chart v1.1.0 from oci://ghcr.io/slinkyproject/charts) as a first-class AICR platform under `--platform slurm`. Ships two components: `slinky-slurm-operator-crds` and `slinky-slurm-operator`, composed by a new `platform-slurm` mixin. Operator depends on cert-manager and the CRDs. Mirrors the operator-only pattern of `--platform dynamo` and `--platform kubeflow`: AICR ships only the platform; cluster-instance CRs (Controller, LoginSet, NodeSet, ...) remain user-authored. Leaf overlays (CSP x accelerator x OS) follow in a separate PR. Notable: chart v1.1.0 silently ignores operator.nodeSelector and webhook.nodeSelector. The registry comment links SlinkyProject/slurm-operator#187 with the verbatim follow-up action once that upstream PR merges and a new chart is published. The `slurm` cluster chart is intentionally deferred to a follow-up PR with its own short alias (e.g. `slurm-cluster`) so `slurm` continues to route to the operator. Verified: make qualify (test-coverage + lint + e2e + scan + license-check) PASS; make check-health COMPONENT=slinky-slurm-operator against a live Kind cluster + chart v1.1.0 PASS in 5.42s.
1 task
25 tasks
ArangoGutierrez
added a commit
to ArangoGutierrez/aicr
that referenced
this pull request
May 15, 2026
…g note Two follow-ups to PR NVIDIA#866 (Slinky slurm-operator), bundled into one post-merge cleanup PR. Platform-enum drift backfill — surfaces NVIDIA#866 did not catch ============================================================ PR NVIDIA#866 added `--platform slurm` to the OpenAPI spec, the Go enum (GetCriteriaPlatformTypes), and docs/user/{cli,api}-reference.md + component-catalog.md. Per the project's enum-audit rule (CLAUDE.md "Documentation updates"), every surface that enumerates platform values should be updated. The following surfaces still showed `kubeflow` only (pre-existing drift predating slurm — `dynamo` and `nim` were already missing): - docs/README.md:11 — glossary Criteria row - docs/contributor/data.md:130 — platform row in criteria table - docs/contributor/validations.md:99 — platform bullet - site/docs/getting-started/index.md:19 — glossary mirror - pkg/recipe/criteria.go:246 — Platform field godoc - pkg/recipe/doc.go:32 — Criteria struct shape comment (was non-alphabetical "kubeflow, dynamo, nim, slurm, any") - pkg/recipe/doc.go:93-98 — CriteriaPlatform* constant listing (was non-alphabetical order) - pkg/api/doc.go:72 — REST API doc was missing slurm entirely (only one of these with factual content drift; rest are ordering) - .claude/skills/analyzing-snapshots/SKILL.md:278 — internal AICR snapshot-analysis skill criteria table All now list `dynamo, kubeflow, nim, slurm` in alphabetical order matching pkg/recipe.GetCriteriaPlatformTypes() (the authoritative Go enum). Per-file delimiter convention preserved: slash-separated in glossary-style parens, comma-separated in tables/godoc. New guard test ============== pkg/recipe/doc_test.go::TestCriteriaPlatformConstantsMatchGetter asserts the CriteriaPlatform* constants and GetCriteriaPlatformTypes() stay in sync. Catches the exact class of drift this commit fixes if a future platform value is added to one but not the other. Catalog node-selector limitation note ===================================== Appends a `**Known limitation:**` clause to the slinky-slurm-operator row in docs/user/component-catalog.md, documenting that chart v1.1.0 silently ignores `operator.nodeSelector` and `webhook.nodeSelector` and linking SlinkyProject/slurm-operator#187 for the upstream fix. The same limitation is already in-line in recipes/registry.yaml; the catalog note surfaces it to readers of the rendered user docs. Originally planned but no longer needed ======================================= While auditing, I had also planned to add Mark's two "optional nits" from NVIDIA#866 — a chart-default verification pointer at defaultVersion in recipes/registry.yaml, and a vacuous-pass guard comment in recipes/checks/slinky-slurm-operator/health-check.yaml. Both turned out to already be in the merged version (Mark applied them himself before merge — see recipes/registry.yaml:550-555 and recipes/checks/slinky-slurm-operator/health-check.yaml:64-69). The .lychee.toml header change is the project's license-header check auto-applying the standard Apache 2.0 copyright block. Addresses ========= Mark (@mchmarny) review feedback on NVIDIA#866: - Doc-audit gap across user docs (cli-reference + api-reference landed at merge time; this PR catches the remaining surfaces) CodeRabbit review feedback on NVIDIA#866: - NodeSelector limitation note on slinky-slurm-operator catalog row Internal panel review (PE + QA + DA) on draft NVIDIA#884: - Extended audit to pkg/api/doc.go (factual miss), pkg/recipe/doc.go (ordering), .claude/skills/analyzing-snapshots/SKILL.md - Added guard test against future enum/getter drift - Squashed to single commit; rebased onto upstream/main HEAD Signed-off-by: Carlos Eduardo Arango Gutierrez <[email protected]>
Contributor
Author
|
merged c4e8959 |
Contributor
|
Merged: c4e8959 |
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.
Summary
The Helm chart did not document or wire
nodeSelectorfor either the operator or webhook Deployment. Helm parsed--set operator.nodeSelector.foo=bar(and the webhook equivalent) into.Valueswithout complaint and silently dropped the value at render time, since no template referenced it and the chart has novalues.schema.jsonfor validation.This PR wires
.Values.operator.nodeSelectorand.Values.webhook.nodeSelectorthroughtemplates/operator/deployment.yamlandtemplates/webhook/deployment.yamlusing the same{{- with ... }}/toYaml | nindent 8idiom already used foraffinityandtolerations, documents the field invalues.yamlwith wording aligned to the siblinghelm/slurmchart, regenerates the matching rows in the values table ofhelm/slurm-operator/README.md, and adds helm-unittest cases that assert the rendered field for both deployments.Reproduction
Checklist
Breaking Changes
Not a breaking API change —
nodeSelectorwas never a documented or supported field on either deployment, and default renders are unchanged (the field is omitted unless the user sets it).There is a latent behavior change worth flagging: any operator who had been setting
operator.nodeSelectororwebhook.nodeSelectorin their values file under the assumption it was being honored will now see the constraint take effect. They should verify their value does not pin pods to nodes that no longer match.Testing Notes
The new helm-unittest cases (
should add nodeSelector) sit alongside the existingshould add affinity/should add tolerationstests in bothtests/operator_deployment_test.yamlandtests/webhook_deployment_test.yaml, following the same shape and depth.