We go the route of having a test cluster and vetting our lua scripts
there before putting them in the production environment.
-Paul Edmon-
On 5/6/2021 1:23 PM, Renfro, Michael wrote:
I’ve used the structure at
https://gist.github.com/mikerenfro/92d70562f9bb3f721ad1b221a1356de5
<https://gist.github.com/mikerenfro/92d70562f9bb3f721ad1b221a1356de5> to
handle basic test/production branching. I can isolate the new behavior
down to just a specific set of UIDs that way.
Factoring out code into separate functions helps, too.
I’ve seen others go so far as to put the functions into separate
files, but I haven’t needed that yet.
On May 6, 2021, at 12:11 PM, Michael Robbert <mrobb...@mines.edu> wrote:
*External Email Warning*
*This email originated from outside the university. Please use
caution when opening attachments, clicking links, or responding to
requests.*
------------------------------------------------------------------------
I’m wondering if others in the Slurm community have any tips or best
practices for the development and testing of Lua job submit plugins.
Is there anything that can be done prior to deployment on a
production cluster that will help to ensure the code is going to do
what you think it does or at the very least not prevent any jobs from
being submitted? I realize that any configuration change in
slurm.conf could break everything, but I feel like adding Lua code
adds enough complexity that I’m a little more hesitant to just throw
it in. Any way to run some kind of linting or sanity tests on the Lua
script? Additionally, does the script get read in one time at startup
or reconfig or can it be changed on the fly just by editing the file?
Maybe a separate issue, but does anybody have an recipes to build a
local test cluster in Docker that could be used to test this? I was
working on one, but broke my local Docker install and thought I’d
send this note out while I was working on rebuilding it.
Thanks in advance,
Mike Robbert
