Missing documentation for JobOptions

[LourensVeen]

There does not seem to be any documentation on which JobOptions can be set in a JobDescription. With some detective work, this is what seems to be supported (grep for VALID_JOB_OPTIONS in the source tree):

Slurm

• JOB_OPTION_JOB_SCRIPT -> "Custom job script"

Torque

• JOB_OPTION_JOB_SCRIPT -> "Custom job script"
• JOB_OPTION_RESOURCES -> "Ask cluster admin"

GridEngine

• JOB_OPTION_JOB_SCRIPT -> "Custom job script"
• JOB_OPTION_PARALLEL_ENVIRONMENT -> "Ask cluster admin?"

I can't find any values for -pe in the GridEngine documentation (http://gridscheduler.sourceforge.net/htmlman/htmlman5/sge_pe.html), and I'm guessing RESOURCES refers to --gres which would be cluster-specific and hopefully documented somewhere. Still, at least the keys should be documented somewhere in the Xenon documentation.

[jmaassen]

We should add a custom JobDescription that only takes a job script as an option ? Or better, have an additional submit that takes a jobscript as parameter.

[jmaassen]

Also see issue #512

[jmaassen]

Also include issue #432

[sverhoeven]

The SchedulerAdaptorDescription should get a Map<String,String>getSupportedJobOptions() method.

Where key is job option key and value is the description.

[jmaassen]

Also include #582

[jmaassen]

Also include #562

[jmaassen]

After some discussion we concluded the following:

• The current options that are supported are all scheduler specific and different for each scheduler. This is a nuisance. It would be better to directly allow the actual scheduler options themselves so you can use google or man pages.
• The most generic approach would be to support addJobOption(String) which allows the user to add any scheduler specific option needed, for example addJobOption("-C gpunode")
• The current addJobOption(String key, String value) is not suited for this, as it does not allow duplicate keys
• Adding an entire jobscript as an option is ugly, this should either be a separate type of JobDescription (a JobScript class maybe), a separate submit method, or be dropped all together

We should take care that the options passed via job options do not class with the values set in the regular manner (like time, node count, etc).

We could support some options as first class citizens, like job dependencies, array jobs, etc ?

[LourensVeen]

Hmm, so then the question is what should be done through a general function, and what should be done in a scheduler-specific manner? If clients end up keeping tables of information about how to get something done for each scheduler, then Xenon is not doing its job of abstracting the scheduler away. On the other hand, we don't want things in the Xenon API that are scheduler-specific.

On some clusters you get a GPU by submitting to a specific queue, on others you have to specify a constraint. There is no way that Xenon can know this, so a useGPU() function doesn't make sense. On the other hand, the time, cores, and memory required should probably be set through a nice scheduler-agnostic API. So maybe it's about whether something is scheduler- or cluster-specific?

[jmaassen]

One suggestion from Atze was to also add more specialized JobDescription subclasses to utils for specific infrastructures. You could add a DAS5JobDescription or CartesiusJobDescription that has all the knowledge you need on these systems.

[sverhoeven]

We could add

Scheduler.submitBatchJob(string jobScript)

And the JobDescription is converted to a jobScript string. Now JobOption functionality can be handled by schedulerarguments and this api addition.

[jmaassen]

Removed JobOptions in #645

No longer an issue.