[BUG]: Empty `Topology=` causes Worker CPU and memory registration failure

[crliu3227]

Version

1.2.1

Which installation method(s) does this occur on?

Helm / Kubernetes manifests

Describe the bug.

Description

When a NodeSet does not configure a Slurm topology, the operator still injects an empty Topology= entry into slurmd --conf.

The container image entrypoint then appends CoreSpecCount and MemSpecLimit. Slurm parses CoreSpecCount as the value of Topology, causing node registration to fail and the Worker to enter DRAIN+INVALID_REG.

Reproduction

Use a NodeSet with CPU and memory limits, without a topology configuration:

apiVersion: slinky.slurm.net/v1beta1
kind: NodeSet
spec:
  slurmd:
    resources:
      limits:
        cpu: "8"
        memory: 16Gi

Do not configure spec.extraConf: Topology=..., and do not provide a valid topology for the Kubernetes node.
Actual behavior
The resource environment variables are correct:

POD_CPUS=8
POD_MEMORY=16384

However, the final slurmd invocation contains:

--conf Features=slinky Topology= CoreSpecCount=36 MemSpecLimit=175607

The controller reports:

Reason=Failed to set topology 'CoreSpecCount=36'
State=IDLE+DRAIN+DYNAMIC_NORM+INVALID_REG
CPUEfctv=80

CoreSpecCount is not applied, so Slurm incorrectly treats all host CPUs as schedulable.
Expected behavior
When topology is not configured, the operator must not generate Topology=.
The final configuration should be:

--conf Features=slinky CoreSpecCount=36 MemSpecLimit=175607

Minimum reproducible example

Relevant log output

Additional environment details

Other/Misc.

No response

Code of Conduct

• I agree to follow Slurm Operator's Code of Conduct
• I have searched the open bugs and have found no duplicates for this bug report

[vivian-hafener]

Good morning @crliu3227,

I will look into this.

Best,
Vivian Hafener

[vivian-hafener]

See: SlinkyProject/slurm-operator#262 (comment)

[vivian-hafener]

Complete reproducer:

1. Deploy kind cluster:

❯ hack/kind.sh --core

2. Create simplest possible NodeSet that aligns with default helm/slurm/values.yaml:

apiVersion: slinky.slurm.net/v1beta1                                                                                                                           
kind: NodeSet
metadata:
  name: simple
  namespace: slurm
spec:
  controllerRef:
    name: slurm
  slurmd:
    image: ghcr.io/slinkyproject/slurmd:26.05-ubuntu26.04
    resources:
      limits:
        cpu: "2"
        memory: 2Gi
  logfile:
    image: docker.io/library/alpine:latest

3. Apply simple.yaml:

❯ kubectl apply -f simple-nodeset.yaml

4. Observe NodeSet pod come up in INVALID_REG:

❯ kubectl exec -n slurm slurm-controller-0 -- scontrol show node
NodeName=simple-0 Arch=x86_64 CoresPerSocket=4 
   CPUAlloc=0 CPUEfctv=4 CPUTot=4 CPULoad=1.66
   AvailableFeatures=simple
   ActiveFeatures=simple
   Gres=(null)
   NodeAddr=10.244.5.3 NodeHostName=simple-0 Version=26.05.4
   OS=Linux 7.0.0-29-generic SlinkyProject/slurm-operator#29~24.04.2-Ubuntu SMP PREEMPT_DYNAMIC Wed Aug 12 17:25:56 UTC 2 
   RealMemory=31571 AllocMem=0 FreeMem=4877 Sockets=1 Boards=1
   MemSpecLimit=29523
   State=IDLE+DRAIN+DYNAMIC_NORM+INVALID_REG ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
   BootTime=2026-08-20T21:52:10 SlurmdStartTime=2026-09-09T16:02:12
   LastBusyTime=2026-09-09T16:02:12 ResumeAfterTime=None SuspendTime=INFINITE
   CfgTRES=cpu=4,mem=31571M,billing=4
   AllocTRES=
   CurrentWatts=0 AveWatts=0
   Reason=Failed to set topology 'CoreSpecCount=2' [slurm@2026-09-09T16:02:12]
   Comment={"namespace":"slurm","podName":"simple-0","node":"kind-worker","nodeSetName":"simple","nodeSetUID":"decadf96-93e3-4965-9469-f8e1e56a840a"}

[vivian-hafener]

Once I've confirmed that this is actually an issue for https://github.com/SlinkyProject/containers, I will transfer it there.