Containers for Execution

As described elsewhere, there are three types of containers related to job execution:

  1. Temporary workspace: created whenever an app, applet is run
  2. Project cache container: container in which data can be cached for future execution by the same version of an app; it is always associated with a particular project
  3. Resources container: created during app creation, containing any resources the app requires for execution

The table below summarizes the permissions that a job running the associated applet or app will receive, as well as the maximum permissions a member of the project context can receive (they must have equal or greater permissions in the project).

Container Job Project Member
Temporary workspace CONTRIBUTE VIEW
Project cache CONTRIBUTE CONTRIBUTE
Resources container VIEW VIEW if app developer; NONE otherwise

Jobs running other applets or apps may in some cases also be able to access the resources container of an app with VIEW permissions, but only if they have been given access to act on behalf of the user as a developer.

Containers for Analyses

Analyses also have temporary workspace containers that are created on their behalf. These containers are used primarily by the system for storing intermediate results for the analysis, and are not meant to be accessed directly by users or jobs. These containers are cleaned up after the associated analysis has transitioned to a terminal state.

List of API Methods

List of Container API Methods

The following are API methods specific to (or have behavior specific to) Containers.

List of Common Container API Methods

The following are API methods common to all data containers (of class "project" or "container") and are defined where the methods are discussed.

Container API Method Specifications

API method: /container-xxxx/describe

Specification

Describes the specified container.

Inputs

  • fields mapping (optional) Restrict the output of this method to have only the provided keys in this field
    • key Desired output field; see the "Outputs" section below for valid values here
    • value boolean The value true

Outputs

  • id string ID of the container (i.e. the string "container-xxxx")

The following fields are included by default (but can be disabled using fields):

  • class string The value "container"
  • name string The name of the container
  • region string The region this container resides in. For more information about regions, see Regions.
  • billTo string ID of the account to which any costs associated with this container will be billed
  • type string The type of container: one of "temporary" (for applet/app execution), "cache" (for apps), or "resources" (for apps)
  • created timestamp Time at which this container was created
  • modified timestamp Time at which this container was last updated
  • level string The highest permissions level that the requesting user has; this field is only returned when called directly, i.e. it does not show up in the describe values returned in /system/findProjects
  • dataUsage number Data usage in GB (not including sponsored data). A short amount of time may elapse between changes to the container and when this number is updated.
  • sponsoredDataUsage number Sum of DNAnexus-sponsored and third-party sponsored data usage in GB. A short amount of time may elapse between changes to the container and when this number is updated.

The following fields (included by default) are available if type is "temporary" or "cache":

  • project string The associated project context

The following fields (included by default) are available if type is "cache" or "resources":

  • app string ID of the associated app
  • appName string Name of the associated app

The following fields (included by default) are available if type is "temporary", the associated job was run with delayWorkspaceDestruction set to true, and the job has finished (successfully or not):

  • destroyAt timestamp Time after which this container will be automatically destroyed

The following fields are only returned if the corresponding field in the fields input is set to true:

  • folders array of strings List of all folders in the container
  • fileUploadParameters mapping Information about what part sizes and numbers should be used to upload files in this container. See the section Limits on Parts of the Files API for more information about interpreting this. Mapping with the key/values:
    • minimumPartSize int minimum part size, in bytes, that applies to all parts except the part with the highest index (Clients may assume that if emptyLastPartAllowed is false, then minimumPartSize will be at least 1, that is, the constraint on the last part is no stronger than the constraint on previous parts.)
    • maximumPartSize int maximum part size, in bytes
    • emptyLastPartAllowed boolean If true, then the the minimum number of parts is 1 and the part with the highest index may contain 0 bytes. If false, then the minimum number of parts is 0 and the part with the highest index must contain at least 1 byte. Note that all parts other than the part with the highest index must still have minimum size given by minimumPartSize. (If true, then the client can upload a 0-byte file by invoking /file-xxxx/upload once with a part of size 0. If false, then the client can upload a 0-byte file by not invoking /file-xxxx/upload at all.)
    • maximumNumParts int the maximum number of parts that may be uploaded (also equal to the largest permissible part index)
    • maximumFileSize int the maximum size of the file, in bytes

Errors

  • ResourceNotFound (the specified container does not exist)
  • InvalidInput (the input is not a hash, folders (if provided) is not a boolean)
  • PermissionDenied (VIEW access required)

Last edited by Sean King, 2016-06-23 22:52:54

 Feedback