[slurm-users] Too many associations
Jackson, Gary L.
Gary.Jackson at jhuapl.edu
Thu Jun 29 20:35:01 UTC 2023
The loophole that I refer to in my previous message refers to the documentation of the "Job Submit Plugin API":
The documentation for `job_submit` claims "[t]his function is called by the slurmctld daemon with the job submission parameters supplied by the salloc, sbatch or srun command." My question is this:
Does that mean users can get around it, for example, with the `slurm_submit_batch_job` API call, referred to in the Slurm API proper?:
As the slurmctld code is written now, it seems that all job submission paths through Slurm get the `job_submit` plugin callback invoked on their behalf, which is great! However, if this is a promise that the API is making, then the API documentation needs to be updated. If not, I have to ask why that's the case.
On 6/29/23, 2:24 PM, "slurm-users on behalf of Jackson, Gary L." <slurm-users-bounces at lists.schedmd.com <mailto:slurm-users-bounces at lists.schedmd.com> on behalf of Gary.Jackson at jhuapl.edu <mailto:Gary.Jackson at jhuapl.edu>> wrote:
APL external email warning: Verify sender slurm-users-bounces at lists.schedmd.com <mailto:slurm-users-bounces at lists.schedmd.com> before clicking links or attachments
We have a set of idiosyncratic requirements imposed on us:
1. There are on the order of 10^3 different budget codes. Maybe even 10^4 once this thing gets cooking. That list will change a little bit every day, and may change a lot at certain times of the year.
2. There are on the order of 10^2 different users.
3. Any user can submit a job to any budget code.
4. A job must be associated with exactly one budget code.
5. Only a very small subset of those budget codes will actually get used, but they will not be enumerated beforehand.
Is there any way to do this that avoids both:
1. Creating an unmanageable number of associations.
2. Doesn’t have a loophole that permits violation of (4) above, which various script-based enforcements do.
I’ve considered automatically managing that ridiculously long list of associations, but that just seems like a bad idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6200 bytes
Desc: not available
More information about the slurm-users