"Mark A. Grondona" <[email protected]> writes: > It would be interesting to know why you need an sbatch wrapper.
We do several things in the wrapper, for instance: - disallow certain arguments or combinations of arguments - joining separate --constraint arguments into one, where the constraints are joined with "&" - checking that the account has not spent all its allowed cpu hours - In times of maintenance, etc., we modify the wrapper to for instance deny job submission alltogether (with an informative message) or jobs with certain constraints (like InfiniBand). - converting some constraints to other, for instance --constraint=ib is converted into --constraint=[ib1|ib2] (to avoid jobs across the two IB switches we have). - adding default values for things like --tmp Several of these could be moved into slurm (sacctmgr), or into a submit or spank plugin. We have already moved some stuff into sacctmgr and a lua job submit plugin, but have not investigated spank plugins yet. We also have a command qlogin that wraps around a call to salloc for easier submission of interactive jobs, and we plan to merge the two wrappers. In general, wrappers can give a higher degree of flexibility, and can present a more stable interface to users when we do underlying changes. For instance, we just went from using Maui+SLURM to only SLURM, and changed how access to our hugemem nodes is specified, from --constraint=hugemem to --partition=hugemem. Our wrapper will rewrite so that old scripts will continue to work. A couple of years ago, when we switched from SGE to Maui+SLURM, we used the wrapper to automatically convert SGE scripts to SLURM scripts (as far as possible) and tell the user what needed to be fixed manually. -- Regards, Bjørn-Helge Mevik, dr. scient, Research Computing Services, University of Oslo
