Regions

In DNAnexus, a region is an abstraction that unifies access to different cloud providers as well as to different geographical regions in which a single cloud provider may operate. By specifying a region for your DNAnexus resources, you can ensure that your files are stored in (and that your jobs are run in) a particular physical location in order to satisfy data locality requirements or latency requirements.

A region is represented by a string of the form "cloud:geo"; for example, "aws:us-east-1" denotes the "us-east-1" geographical region of the AWS cloud.

  • Projects and files have affinity to a particular region. A region is chosen for a project at creation time and is fixed throughout the lifetime of the project. All files uploaded to that project will be stored in object storage in the specified region, and all jobs run in that project will be run on instances located in the specified region.
  • You can clone files between projects in the same region. The DNAnexus Platform does not currently support transferring files or projects across regions. For example, you cannot clone a file in one region to a project of a different region.
  • Users and organizations have a set of permitted regions that they are allowed to use. In order to create a project in a particular region, the region must be among the permitted regions of the project's billTo. Please contact DNAnexus support if you wish to obtain access to additional regions.
  • Users and organizations have a default region, which may be set by the user (or organization administrators, respectively) to any value among the permitted regions. This is the default region that is used when a new project is created and a region is not otherwise specified.

The following API routes consume or return regions:

  • /user-xxxx/describe and /org-xxxx/describe provide access to the permitted regions and default region of a profile (accessible as permittedRegions and defaultRegion, respectively). If you have permission to see the pricing models of the profile, those are also keyed by region (reflecting possibly different price sheets and instance types available in each region).
  • /user-xxxx/update and /org-xxxx/update allow updates to the defaultRegion field of a profile.
  • /project/new allows setting the region with which the newly created project will be associated.
  • /project-xxxx/describe and /container-xxxx/describe show the region with which the project or container is associated.

Region has implications for, among others, the following operations:

  • In /project-xxxx/clone and /container-xxxx/clone it only allowed to clone data objects from one container to another if the two containers have the same region.
  • As a special case of the above, if an app or applet is to be run in a project, the bundledDepends associated with the executable, the inputs to the executable, and the project itself must exist in the same region.
  • Changing the billTo of a project via /project-xxxx/update or /project-xxxx/acceptTransfer is only permitted if the region of the project is among the permittedRegions of the destination billTo.

Last edited by Phil Sung, 2016-05-16 20:25:21

 Feedback