[slurm-users] On the ability of coordinators
Brian Andrus
toomuchit at gmail.com
Wed May 17 16:58:34 UTC 2023
If they have the permissions, you can just raise the priority of user
B's jobs to be higher than whatever A's currently are. Then they will
run next.
That will work if you are able to wait for some jobs to finish and you
can 'skip the line' for the priority jobs.
If you need to preempt running jobs, that would take a bit more effort
to set up, but is an alternative.
Brian Andrus
On 5/17/2023 6:40 AM, Groner, Rob wrote:
> I was asked to see if coordinators could do anything in this scenario:
>
> * Within the account that they coordinated, User A submitted 1000s
> of jobs and left for the day.
> * Within the same account, User B wanted to run a few jobs really
> quickly. Once submitted, his jobs were of course behind User A's
> jobs.
> * The coordinator wanted to see the results of User B's runs.
>
> Reading the docs and doing some experiments, here is what I determined:
>
> * The coordinator could put a hold on all of User A's jobs in the
> pending queue. This won't affect any jobs User A has that aren't
> tied to the coordinated account.
> * With User A's jobs held, then User B's jobs would be next to run.
> * If the coordinator was particularly impatient, he could scancel
> User A's currently running jobs so that User B's jobs immediately
> started.
> * The coordinator would need to remember to release the held jobs,
> or put them in a uhold so that User A could release them eventually.
>
> It seems like the easiest way for the coordinator to elevate User B's
> jobs to the top of the queue would be if he could "scontrol top" those
> jobs. But my testing indicates that the coordinator doesn't have that
> permission. Is there some reason that a coordinator can't use
> "scontrol top" to change the priority of jobs within the account that
> he coordinates?
>
> Thanks.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20230517/5adb4f61/attachment.htm>
More information about the slurm-users
mailing list