Well, there could be a way: make them "pay" (in some way) for the
requested resources.
Payment can be anything: in our case, the more resources one user
allocates the less priority his group gets. If there are enough users
impacted by bad behaviour they'll be your allies (if they have access to
There's no clear answer to this. It depends a bit on how you've segregated
your resources.
In our environment, GPU and bigmem nodes are in their own partitions.
There's nothing to prevent a user from specifying a list of potential
partitions in the job submission, so there would be no need for the
Indeed. We use this and BELIEVE that it works, lol!
Bill
function slurm_job_modify ( job_desc, job_rec, part_list, modify_uid )
if modify_uid == 0 then
return 0
end
if job_desc.qos ~= nil then
return 1
end
return 0
end
On
As far a I remember you can use the job_submit lua plugin to prevent any
change on the jobs
On Thu, 16 Dec 2021 at 21:47, Bernstein, Noam CIV USN NRL (6393) Washington
DC (USA) wrote:
> Is there a meaningful difference between using "scontrol update" and just
> killing the job and resubmitting w
Is there a meaningful difference between using "scontrol update" and just
killing the job and resubmitting with those resources already requested?
Hi everyone,
I was wondering if there is a way to prevent users from updating their jobs
with "scontrol update job".
Here is the justification.
A hypothetical user submits a job requesting a regular node, but
he/she realises that the large memory nodes or the GPU nodes are idle.
Using the previo
