|container_uuid|string|The uuid of the container that satisfies this container_request. The system may return a preexisting Container that matches the container request criteria. See "Container reuse":#container_reuse for more details.|Container reuse is the default behavior, but may be disabled with @use_existing: false@ to always create a new container.|
|container_count_max|integer|Maximum number of containers to start, i.e., the maximum number of "attempts" to be made.||
|mounts|hash|Objects to attach to the container's filesystem and stdin/stdout.|See "Mount types":#mount_types for more details.|
+|secret_mounts|hash|Objects to attach to the container's filesystem. Only "json" or "text" mount types allowed.|Not returned in API responses. Reset to empty when state is "Complete" or "Cancelled".|
|runtime_constraints|hash|Restrict the container's access to compute resources and the outside world.|Required when in "Committed" state. e.g.,<pre><code>{
"ram":12000000000,
"vcpus":2,
|cwd|string|Initial working directory, given as an absolute path (in the container) or a path relative to the WORKDIR given in the image's Dockerfile.|Required.|
|command|array of strings|Command to execute in the container.|Required. e.g., @["echo","hello"]@|
|output_path|string|Path to a directory or file inside the container that should be preserved as container's output when it finishes. This path must be one of the mount targets. For best performance, point output_path to a writable collection mount. See "Pre-populate output using Mount points":#pre-populate-output for details regarding optional output pre-population using mount points and "Symlinks in output":#symlinks-in-output for additional details.|Required.|
-|output_name|string|Desired name for the output collection. If null, a name will be assigned automatically.||
+|output_name|string|Desired name for the output collection. If null or empty, a name will be assigned automatically.||
|output_ttl|integer|Desired lifetime for the output collection, in seconds. If zero, the output collection will not be deleted automatically.||
|priority|integer|Range 0-1000. Indicate scheduling order preference.|Clients are expected to submit container requests with zero priority in order to preview the container that will be used to satisfy it. Priority can be null if and only if state!="Committed". See "below for more details":#priority .|
|expires_at|datetime|After this time, priority is considered to be zero.|Not yet implemented.|
|use_existing|boolean|If possible, use an existing (non-failed) container to satisfy the request instead of creating a new one.|Default is true|
-|log_uuid|string|Log collection containing log messages provided by the scheduler and crunch processes.|Null if the container has not yet completed.|
+|log_uuid|string|Log collection containing log messages provided by the scheduler and crunch processes.|Null if the container has not yet started running.|
|output_uuid|string|Output collection created when the container finished successfully.|Null if the container has failed or not yet completed.|
|filters|string|Additional constraints for satisfying the container_request, given in the same form as the filters parameter accepted by the container_requests.list API.|
+|runtime_token|string|A v2 token to be passed into the container itself, used to access Keep-backed mounts, etc. |Not returned in API responses. Reset to null when state is "Complete" or "Cancelled".|
+|runtime_user_uuid|string|The user permission that will be granted to this container.||
+|runtime_auth_scopes|array of string|The scopes associated with the auth token used to run this container.||
+|output_storage_classes|array of strings|The storage classes that will be used for the log and output collections of this container request|default is ["default"]|
+|output_properties|hash|User metadata properties to set on the output collection. The output collection will also have default properties "type" ("intermediate" or "output") and "container_request" (the uuid of container request that produced the collection).|
+|cumulative_cost|number|Estimated cost of the cloud VMs used to satisfy the request, including retried attempts and completed subrequests, but not including reused containers.|0 if container was reused or VM price information was not available.|
+
+h2(#lifecycle). Container request lifecycle
+
+A container request may be created in the Committed state, or created in the Uncommitted state and then moved into the Committed state.
+
+Once a request is in the Committed state, Arvados locates a suitable existing container or schedules a new one. When the assigned container finishes, the request state changes to Final.
+
+A client may cancel a committed request early (before the assigned container finishes) by setting the request priority to zero.
+
+!{max-width:40em;max-height:70em}{{site.baseurl}}/api/methods/container_request_lifecycle.svg!
+{% comment %}
+# svg generated using https://dreampuf.github.io/
+digraph {
+ graph [nojustify=true] [labeljust=l];
+
+ invisiblestart [label = ""] [color=white];
+ node [color=black] [fillcolor=white] [style=filled] [shape=box] [nojustify=true];
+ uncommitted [label = "container request:\l state=Uncommitted\l"] [fillcolor=lightgrey];
+ committed [label = "container request:\l state=Committed\l priority>0\l"];
+ invisiblestart -> uncommitted [label = "user creates container request"] [color=navy] [fontcolor=navy];
+ uncommitted -> committed [label = "user updates to\lstate=Committed, priority>0\l"] [color=navy] [fontcolor=navy];
+ queued [label = "container request:\l state=Committed\l priority>0\lcontainer:\l state=Queued\l"];
+ committed -> queued [label = "Arvados creates\la new container\l"];
+ locked [label = "container request:\l state=Committed\l priority>0\lcontainer:\l state=Locked\l"];
+ queued -> locked [label = "Arvados is ready\lto dispatch the container\l"];
+ running [label = "container request:\l state=Committed\l priority>0\lcontainer:\l state=Running\l"];
+ locked -> running [label = "Arvados starts the\lcontainer process\l"];
+
+ node [color=black] [fillcolor=lightblue] [style=filled] [shape=box];
+ reused [label = "container request:\l state=Final\lcontainer:\l state=Complete\l(reused existing container)\l"];
+ latecancelled [label = "container request:\l state=Final\lcontainer:\l state=Cancelled\l"];
+ containerfinished [label = "container request:\l state=Final\lcontainer:\l state=Complete\l exit_code=0\l"];
+ containerfailed [label = "container request:\l state=Final\lcontainer:\l state=Complete\l exit_codeā 0\l"];
+
+ committed -> reused [label = "Arvados selects an\lexisting container\l"];
+ queued -> latecancelled [label = "user updates to\lpriority=0\l"] [color=navy] [fontcolor=navy];
+ locked -> latecancelled [label = "user updates to\lpriority=0\l"] [color=navy] [fontcolor=navy];
+ running -> latecancelled [label = "user updates to\lpriority=0\l"] [color=navy] [fontcolor=navy];
+ running -> containerfailed [label = "container process\lfails\l"];
+ running -> containerfinished [label = "container process\lsucceeds\l"];
+
+ # layout hacks
+ committed -> containerfinished [style=invis];
+ uncommitted -> latecancelled [style=invis];
+ reused -> latecancelled [style=invis];
+}
+{% endcomment %}
h2(#priority). Priority
Priority 1000 is the highest priority.
-The actual order that containers execute is determined by the underlying scheduling software (e.g. SLURM) and may be based on a combination of container priority, submission time, available resources, and other factors.
+The actual order that containers execute is determined by the underlying scheduling software (e.g. Slurm) and may be based on a combination of container priority, submission time, available resources, and other factors.
In the current implementation, the magnitude of difference in priority between two containers affects the weight of priority vs age in determining scheduling order. If two containers have only a small difference in priority (for example, 500 and 501) and the lower priority container has a longer queue time, the lower priority container may be scheduled before the higher priority container. Use a greater magnitude difference (for example, 500 and 600) to give higher weight to priority over queue time.
h2(#container_reuse). Container reuse
-When a container request is "Committed", the system will try to find and reuse an existing Container with the same command, cwd, environment, output_path, container_image, mounts, and runtime_constraints being requested. (Hashes in the serialized fields environment, mounts and runtime_constraints are compared without regard to key order.)
+When a container request is "Committed", the system will try to find and reuse an existing Container with the same command, cwd, environment, output_path, container_image, mounts, secret_mounts, runtime_constraints, runtime_user_uuid, and runtime_auth_scopes being requested. (Hashes in the serialized fields environment, mounts and runtime_constraints use normalized key order.)
In order of preference, the system will use:
* The first matching container to have finished successfully (i.e., reached state "Complete" with an exit_code of 0) whose log and output collections are still available.
A container request may be canceled by setting its priority to 0, using an update call.
-When a container request is canceled, it will still reflect the state of the Container it is associated with via the container_uuid attribute. If that Container is being reused by any other container_requests that are still active, i.e., not yet canceled, that Container may continue to run or be scheduled to run by the system in future. However, if no other container_requests are using that Contianer, then the Container will get canceled as well.
+When a container request is canceled, it will still reflect the state of the Container it is associated with via the container_uuid attribute. If that Container is being reused by any other container_requests that are still active, i.e., not yet canceled, that Container may continue to run or be scheduled to run by the system in future. However, if no other container_requests are using that Container, then the Container will get canceled as well.
h2. Methods
Required arguments are displayed in %{background:#ccffcc}green%.
+Supports federated @create@, @delete@, @get@, @list@, and @update@.
+
h2(#create). create
Create a new container request.
table(table table-bordered table-condensed).
|_. Argument |_. Type |_. Description |_. Location |_. Example |
{background:#ccffcc}.|container_request|object|Container request resource.|request body||
-
+|cluster_id|string|The federated cluster to submit the container request.|query||
The request body must include the required attributes command, container_image, cwd, and output_path. It can also inlcude other attributes such as environment, mounts, and runtime_constraints.
h3. list
-List container_requests.
+List container requests.
See "common resource list method.":{{site.baseurl}}/api/methods.html#index
-See the create method documentation for more information about container request-specific filters.
+The @filters@ argument can also filter on attributes of the container referenced by @container_uuid@. For example, @[["container.state", "=", "Running"]]@ will match any container request whose container is running now.
h3. update
projects / arvados.git / blobdiff