[andriishestakov]

Mount %s-slurm-scripts configmap to worker if cluster name is set

[Uburro]

@andriishestakov I understand the problem, but ...

The injected entries are unconditional and unguarded. If a NodeSet's values already contain a mount named slurm-scripts at /opt/slurm_scripts, the rendered pod gets duplicate volume names and duplicate mountPaths. Both rejected by API validation (must be unique), so the StatefulSet never rolls.

CM naming duplicated across charts, and not identically. slurm-cluster computes it as default .Chart.Name .Values.clusterName | trunc 63 | trimSuffix "-" + -slurm-scripts. The new helper skips both the .Chart.Name fallback and the trunc 63, so an empty or >63-char clusterName produces divergent names (silent no-mount, or a reference to a CM that doesn't exist → pods stuck in ContainerCreating). An explicit slurmScriptsConfigMapName value that defaults to the convention would decouple the two charts.

[andriishestakov]

Added checks for slurm-cluster and nodesets.

[asteny]

@andriishestakov Hello!

Thanks for the updates. The explicit ConfigMap name and duplicate-name checks address part of the review, but a few issues remain before this can be merged:

1. The templates check only existing mount names, not mount paths. A user can still have a mount with another name but with mountPath: /opt/slurm_scripts. The chart will inject another mount at the same path, producing an invalid or ambiguous pod specification. Please check both name and normalized mountPath in the NodeSet and login configurations.

2. nodesets.slurmScriptsCMName still returns an empty string when clusterName is empty, while the slurm-cluster chart falls back to .Chart.Name. This means the NodeSet silently skips the mount with default values. Please use the same fallback in both charts, or require and validate an explicit slurmScriptsConfigMapName.

3. Please add Helm tests covering:

• an existing mount with the same name;
• an existing mount with a different name but the same mountPath;
• an empty clusterName;
• an explicit slurmScriptsConfigMapName;
• a long clusterName.

Once these cases are handled, the original collision and naming concerns should be fully resolved.