2.0 - Scheduler Variables

[pflarr]

Each scheduler needs to populate a set of test config variables that the rest of the config can use in its strings. This is essentially the super-set of all variables any scheduler might consider setting.

Variable Name	Meaning	Values/Type
num_nodes	The number of nodes on which the test will run. Zero denotes that it is executed on a front-end (schedulers need not support this).	Integer >= 0.
procs_per_node	The number of ranks per node on which the test will run.	Integer > 0
qos	The job's 'Quality of Service'.	string (possibly empty)
reservation	The job's reservation.	string (possibly empty)
partition	The job's partition	string (possibly empty)
account	The job's account	string (possibly empty)
down_nodes	The number of down nodes at run time.	integer >= 0
unused_nodes	The number of nodes that weren't used for this test.	integer >= 0
busy_nodes	The number of nodes that would have been acquired, but couldn't be because of other jobs.	integer >= 0
chunk_size	The number of nodes per job chunk, for when we can't reasonably schedule a test across an entire cluster in a single job.	Integer >= 0, typically equal to num_nodes

[pflarr]

Feel free to add any more that you can think of. I made up a few I think will be useful for result logging.

[nicholas-sly]

It occurs to me that num_nodes might be better as a string that can be parsed to be:

1. A number that can be directly cast to an integer for a precise number of nodes. 0 can still denote the front-end node or 'current' node.
2. A range denoted by the presence of a hyphen in any position other than the first or last.
3. A minimum number of nodes denoted by the presence of a hyphen in the first position of the string.

This can be useful for the automated/continuous testing efforts to provide more flexibility in the demands. As I understand it, Slurm is capable of handing analogues to all of these use-cases. Presumably other schedulers are as well.

Thoughts, @pflarr ?

[pflarr]

It's up to the scheduler to interpret these values. They're always handled as strings.

…

On Mon, Nov 26, 2018 at 1:02 PM Nicholas Sly ***@***.***> wrote: It occurs to me that num_nodes might be better as a string that can be parsed to be: 1. A number that can be directly cast to an integer for a precise number of nodes. 0 can still denote the front-end node or 'current' node. 2. A range denoted by the presence of a hyphen in any position other than the first or last. 3. A minimum number of nodes denoted by the presence of a hyphen in the first position of the string. This can be useful for the automated/continuous testing efforts to provide more flexibility in the demands. As I understand it, Slurm is capable of handing analogues to all of these use-cases. Presumably other schedulers are as well. Thoughts, @pflarr <https://github.com/pflarr> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADFpRAFfojxdmbF6o_Ddz966DIQkl2qks5uzEjWgaJpZM4X6eoH> .

-- Paul Ferrell pflarr@gmail.com