JOB CLASS (JC) ============== - JCs simplyfy the way to describe/setup job runtime environments - Several attributes so far used to describe queues (Q) are part of JCs - Each JC may relate to one or more Qs - Each Q may be assigned to one or more JCs - Each job (J) has exact one JC which may be defined during job submittion - Js will have a "default JC" if no one was specified - Each "default Q" will be assigned to the "default JC" j ----- 1 : +-------> | J | <-------+ : i | ----- | 1 | | | | | | v v ----- n:m ------ | Q | <---------------> | JC | ----- ------ - Client application (qsub, qrsh, ...) can overwrite corresponding attributes as defined in JCs. - The JC object allows the admin to specify which of the attributes can be overwritten by the command-line and which can't - Attributes of Qs and the relations between Qs and other objects like parallel environments (PE) and checkpointing objects (CKPT) define the maximum amount of resources a Q can offer. - Attributes of JCs the relation between JC and J defines the minimum requirements a job has, to be executed successfully. Client Interface ================ Visible Attributes ------------------ - Fields below are new JC attributes: jcname user_list access list xuser_list access list command_line 'none' or a commandline similar to qsub/qalter-commandlines which will be used to modify submitted jobs: The first letter of each used option indicates whether an attribute of the JC specification may be overwritten or not. - ===> option might be overwritten by the user ! ===> option can't be overwritten. If a user tries this he will get an error + ===> The submitter of a jobs has to use this option to overwrite the specification e.g "!pe nodeXY 4 -ckpt ckpt1 +l a=solaris64 !-l lic=1 -q small_ckpt.q" Options not used in the JC commandline might be used by the user (similar to -). Multiple use of '?l' provides the possibilty to force certain resource requests whereas others have to or might be provided by the user. - Following Attributes will be moved from the Q object definition into the JC. Corresponding values are default values for new JCs and default values for the "default JC": rerun FALSE shell /bin/csh shell_start_mode NONE prolog NONE epilog NONE starter_method NONE suspend_method NONE resume_method NONE terminate_method NONE notify 00:00:60 fshare 0 oticket 0 qconf ----- -aattr job_class ,... -Aattr job_class ,... -dattr job_class ,... -Dattr job_class ,... -mattr job_class ,... -Mattr job_class ,... -rattr job_class ,... -Rattr job_class ,... -ajc -Ajc -djc -Djc -mjc -Mjc -sjc -sjcl qsub, qalter, qsh, qrsh, qacct, qlogin -------------------------------------- -jc specify JC during submittion/modification/queries qmod ---- -r reschedule all jobs of a certain JC qmon ---- - new entry for job classes in the main window - new "Job Class Control" dialog * similar to "Queue Control" dialog * List of available JCs * Add/Modify/Delete * Refresh/Done/Help Button * Button to "Ticket Overview Dialog" * Reschedule Button - new "Job Class Configuration" to add and modify JCs * similar to "Queue Configuration" dialog (name, queue_list, Tab control) * General Configuration Tab (Slots, Shell, Start mode, Notify Time, Rerun Flag) * Execution Method Tab (Prolog, Epilog, *Method) * Limits Tab - modification of the "Queue Configuration" dialog * removal of moved attributes ------------------------------------------------------------------------------- QSUB/QALTER/... =============== Command line clients and qmon accepting the '-pe' option should either accept -pe or -pe -pe_slots format. This whould give an administartor the possibility to force a certain pe whereas the slot specification might be overwritten by the user ("!pe pe_name +pe_slots 4) ------------------------------------------------------------------------------- Questions (and answers) ======================= 1) Which possibility do we have to be able to specify wether or not individual resources can be overwritten rather then an entire resource specification? Multiple '-l' parameters might be used to express that. e.g. "!l a=solaris -l x=1 +l y=1" --- 2) Is there a way to replace the qtask file using JCs? - Jobs without JC specification implicitely request a JC which has the same name like the job script. - If this JC does not exist than the "default JC" will be used. - Client applications like qtcsh (possibly in future also qsub and qrsh) request the list of configured JC names. e.g. a) qtcsh> netscape might either be executed locally if no netscape-JC exists or it might result in a call to "qrsh -jc netscape netscape". b) qsub/qrsh netscape implicitely requests the netscape-JC but if this JC does not exist than the "default JC" will be used. (something like "qsub -soft -jc netscape netscape") c) qsub -jc ns netscape ns-JC has to exist otherwise the user will get an error message. --- 3) Which syntax might be used to define - a minimum/maximum - default value for numeric expressions (3600 <= j_cpu <= 9600; default = 3600) ? ??? --- 4) There is some overlapping between - sge_request - JC command line - complex default with regards to default resource requests of jobs. Do we know in which cases we will recommend complex based defaults and in which case we will recommend JC default requests? Are both needed? How do they interoperate in case both are used? Is it possible to get rid of complex defaults? ??? --- 5) Hierarchical view / Inheritance of JC attributes? ??? --- 6) Should it be possible to support a job script in the command_line of a JC definition? ??? --- 7) What will happen if a JC changes after submittion of a job? ??? --- 8) Do we need the system wide sge_request files ith JC's ??? --- 9) Should JC replace the job classes scheme (queue based) used in SGEEE? Which customer scenarions could not be expressed by a replacement? ???