[ohtanim]

…nv var

Description of Change

Summary

Pass the --qpu option value to slurmctld at submission time by calling
spank_job_control_setenv(sp, "QRMI_QPU", <value>, 1) in the allocator
context (sbatch / salloc / srun).

Motivation

Currently the --qpu value is only available to the plugin itself. Site-side
components running in slurmctld, such as job_submit plugins, have no reliable
way to see which QPU(s) a job requested. Parsing #SBATCH lines from the
batch script is fragile: it misses --qpu given on the command line and does
not work for salloc/srun.

With this change, slurmctld receives the value through the job's
spank_job_env, which lets sites enforce policies at submit time — for
example, requiring a matching license for each requested QPU:

-- job_submit.lua
for _, kv in ipairs(job_desc.spank_job_env or {}) do
    local qpu = kv:match("^QRMI_QPU=(.*)$")
    if qpu then
        -- e.g. require --licenses=<host>@slurmdb:1 for each host in qpu
    end
end

Changes

• In slurm_spank_init_post_opt, when running in S_CTX_ALLOCATOR and
  --qpu was given, call spank_job_control_setenv(sp, "QRMI_QPU", value, 1).
• The variable is prefixed with QRMI_ to avoid collisions with other
  SPANK plugins or site tooling.

Where the value is visible

Where	Name
slurmctld (job_desc.spank_job_env in job_submit plugins)	QRMI_QPU
Job environment / prolog / epilog	SLURM_SPANK_QRMI_QPU

Testing

• Submitted a job with #SBATCH --qpu=<host> and confirmed that
  job_desc.spank_job_env in a job_submit Lua plugin contains
  QRMI_QPU=<host>.
• Confirmed that jobs without --qpu are unaffected.

Checklist ✅

• Have you included a description of this change?
• Have you updated the relevant documentation to reflect this change?
• Have you made sure CI is passing before requesting a review?

Ticket

• Fixes #
• Is Part of #

[awennersteen]

good catch. lgtm