Not having a separate test environment, I put logic into my job_submit.lua to
use either the production settings or the ones under development or testing,
based off the UID of the user submitting the job:
=====
function slurm_job_submit(job_desc, part_list, submit_uid)
test_user_table = {}
test_user_table[ENTER_USER_UID_HERE] = 'a_username'
test_enabled = (test_user_table[submit_uid] ~= nil)
-- test_enabled = false
if (test_enabled) then -- use logic for testing
slurm.log_info("testing mode enabled")
-- call other functions as needed for testing
else -- use default logic for production
slurm.log_info("production mode enabled")
-- call other functions as needed for production
end -- detect if testing or production
return slurm.SUCCESS
end
=====
I can set test_enabled to false if I want to disable testing entirely,
otherwise, I can make a table of my test user population. I don't think I've
had anyone's production jobs fail when I'm making changes this way, but I'm not
100% certain that a syntax error in functions used in the testing branch would
be ignored in the production branch. And I've tried to modularize as much as I
can into separate functions outside the slurm_job_submit function.
On 9/23/20, 11:09 AM, "slurm-users on behalf of SJTU"
<slurm-users-boun...@lists.schedmd.com on behalf of weijian...@sjtu.edu.cn>
wrote:
External Email Warning
This email originated from outside the university. Please use caution when
opening attachments, clicking links, or responding to requests.
________________________________
Hi,
Modifying and testing job_submit.lua on a production SLURM system may lead
to temporary failure of job submission, which halts new scheduling strategies
being applied. Is it possible to mock a SLURM system to debug job_submit.lua so
that it can be updated to the production system confidently later?
Thank you!
Jianwen
