@@ -207,6 +207,14 @@ The following table describes all available generic information:
|declare a string to be used as options separator in <<../user/ProActiveUserGuide.adoc#_dockerfile,Dockerfile script engine>>.
|job-level, task-level
|!SPLIT!
|<<_job_planner,calendar.name>>
|generic information automatically added by the Job Planner. It contains the name of the calendar based on which the job is planned.
|job-level
|every_10_minutes
|<<_job_planner,next.execution>>
|generic information automatically added by the Job Planner. It contains the next execution date of the job.
|job-level
|2022-04-26 12:50:00 CEST
|===
==== START_AT
...
...
@@ -264,9 +272,9 @@ The general format of the `REMOVE_DELAY` generic information is `VVd XXh YYm ZZs
The format allows flexible combinations of the elements:
* `12d 1h 10m`: 12 days, 1 hour and 10 minutes.
* `26h`: 26 hours.
* `120m 12s`: 120 minutes and 12 seconds.
* `12d 1h 10m`: 12 days, 1 hour and 10 minutes.
* `26h`: 26 hours.
* `120m 12s`: 120 minutes and 12 seconds.
`REMOVE_DELAY` can be defined at *job-level* only.
...
...
@@ -283,9 +291,9 @@ The general format of the `REMOVE_DELAY_ON_ERROR` generic information is `VVd XX
The format allows flexible combinations of the elements:
* `12d 1h 10m`: 12 days, 1 hour and 10 minutes.
* `26h`: 26 hours.
* `120m 12s`: 120 minutes and 12 seconds.
* `12d 1h 10m`: 12 days, 1 hour and 10 minutes.
* `26h`: 26 hours.
* `120m 12s`: 120 minutes and 12 seconds.
`REMOVE_DELAY_ON_ERROR` can be defined at *job-level* only.
...
...
@@ -348,8 +356,8 @@ More information is available in the <<_save_script>> section.
`NS` (short for *Native Scheduler*), `NS_BATCH` and `NS_PRE` are Generic Information used to deploy and configure workflow tasks inside a *Native Scheduler infrastructure*.
* `NS`: execute a task associated with this generic information inside a ProActive Node Source interacting with a native scheduler. The value of this generic information must be equal to the node source name. Example: `NS=Slurm`.
* `NS_BATCH`: allows to provide additional parameters to the native scheduler. Example: `NS_BATCH=-q queue1 -lnodes=2:ppn=2`.
* `NS`: execute a task associated with this generic information inside a ProActive Node Source interacting with a native scheduler. The value of this generic information must be equal to the node source name. Example: `NS=Slurm`.
* `NS_BATCH`: allows to provide additional parameters to the native scheduler. Example: `NS_BATCH=-q queue1 -lnodes=2:ppn=2`.
* `NS_PRE`: allows to provide a single line command which will be executed before the ProActive Node on the cluster. Example: `NS_PRE=module load mpi/gcc/openmpi-1.6.4`.
See <<../admin/ProActiveAdminGuide.adoc#_execute_tasks_on_a_native_scheduler_node_source,Execute Tasks on a Native Scheduler Node Source>> for more information.
...
...
@@ -398,9 +406,9 @@ The following generic information can be used to assign result metadata to a wor
Can only be used if the task result content is an array of bytes.
* `content.type`: define the MIME type of the result.
* `file.name`: allows to store (Save as) the result from the scheduer or workflow-automation portals as a specific file name.
* `file.extension`: allows to store (Save as) the result from the scheduer or workflow-automation portals as a specific file extension with auto-generated file name.
* `content.type`: define the MIME type of the result.
* `file.name`: allows to store (Save as) the result from the scheduler or workflow-automation portals as a specific file name.
* `file.extension`: allows to store (Save as) the result from the scheduler or workflow-automation portals as a specific file extension with auto-generated file name.
See <<../user/ProActiveUserGuide.adoc#_assigning_metadata_to_task_result,Assigning metadata to task result>> for further information.
...
...
@@ -420,9 +428,9 @@ See <<../user/ProActiveUserGuide.adoc#_python,Python script language>> for furth
When using <<../user/ProActiveUserGuide.adoc#_docker_compose,Docker Compose>> tasks, the following generic information can be used to control options given to `docker-compose` commands:
* `docker-compose-options`: general parameters given to the docker-compose command.
* `docker-compose-up-options`: options given to the `docker-compose up` command.
* `docker-compose-options-split-regex`: declare a string to be used as options separator.
* `docker-compose-options`: general parameters given to the docker-compose command.
* `docker-compose-up-options`: options given to the `docker-compose up` command.
* `docker-compose-options-split-regex`: declare a string to be used as options separator.
See <<../user/ProActiveUserGuide.adoc#_docker_compose,Docker Compose script language>> for further information.
...
...
@@ -432,18 +440,25 @@ The Docker Compose generic information should be defined at *task-level* but can
When using <<../user/ProActiveUserGuide.adoc#_dockerfile,Dockerfile>> tasks, the following generic information can be used to control options given to `docker` commands:
* `docker-actions`: actions to perform. A comma separated list of possible actions (build, run, exec, stop, rmi). Default is `build,run,stop,rmi`.
* `docker-image-tag`: tag identifying the docker image. Default is `image_${PA_JOB_ID}t${PA_TASK_ID}`
* `docker-container-tag`: tag identifying the docker container. Default is `container_${PA_JOB_ID}t${PA_TASK_ID}`
* `docker-build-options`: options given to the `docker build` command.
* `docker-run-options`: options given to the `docker run` command.
* `docker-exec-command`: command given to `docker exec`, if used in `docker-actions`. If the command contains spaces, `docker-file-options-split-regex` should be used to split command parameters.
* `docker-exec-options`: options given to the `docker exec` command. Default is `-t` (which should always be included).
* `docker-stop-options`: options given to the `docker stop` command.
* `docker-rm-options`: options given to the `docker rm` command.
* `docker-rmi-options`: options given to the `docker rmi` command.
* `docker-file-options-split-regex`: declare a string to be used as options separator, instead of the `space` character.
* `docker-actions`: actions to perform. A comma separated list of possible actions (build, run, exec, stop, rmi). Default is `build,run,stop,rmi`.
* `docker-image-tag`: tag identifying the docker image. Default is `image_${PA_JOB_ID}t${PA_TASK_ID}`
* `docker-container-tag`: tag identifying the docker container. Default is `container_${PA_JOB_ID}t${PA_TASK_ID}`
* `docker-build-options`: options given to the `docker build` command.
* `docker-run-options`: options given to the `docker run` command.
* `docker-exec-command`: command given to `docker exec`, if used in `docker-actions`. If the command contains spaces, `docker-file-options-split-regex` should be used to split command parameters.
* `docker-exec-options`: options given to the `docker exec` command. Default is `-t` (which should always be included).
* `docker-stop-options`: options given to the `docker stop` command.
* `docker-rm-options`: options given to the `docker rm` command.
* `docker-rmi-options`: options given to the `docker rmi` command.
* `docker-file-options-split-regex`: declare a string to be used as options separator, instead of the `space` character.
See <<../user/ProActiveUserGuide.adoc#_dockerfile,Dockerfile script language>> for further information.
The Dockerfile generic information should be defined at *task-level*. Some (docker-file-options-split-regex, or command options) may be defined at *job-level* to apply to all tasks of the workflow.
\ No newline at end of file
The Dockerfile generic information should be defined at the *task level*. Some (docker-file-options-split-regex, or command options) may be defined at the *job level* to apply to all tasks of the workflow.
==== Job Planner
The <<../JobPlanner/JobPlannerUserGuide.html#_all_doc_jp_user_guide, Job Planner>> automatically adds two generic information to the jobs it submits:
* `calendar.name`: the calendar name based on which the job is planned.
* `next.execution`: the next execution date of the planned job. The date is formatted with respect to the pattern `yyyy-MM-dd HH:mm:ss z` and considers the time zone specified in the Job Planner configuration.
When no time zone is specified, the default time zone of ProActive server is considered.
