General Attributes for Objects in Orchestrations v2

Any object that you define in an orchestration, regardless of the object type, has certain general attributes.

The following is a JSON template for an orchestration, with the general attributes for objects highlighted. The table that follows the template contains the descriptions for these attributes.

  "name": "/Compute-identity_domain/user/orchestration_name",	
  "description": "OrchestrationDescriptionHere",
  "desired_state": "state",
  "tags": ["sometag","sometag2"],
  "objects": [
      "label": "someText",
      "type": "objectType",
      "desired_state": "inherit",
      "template": {
      "name": "objectName",
      "description": "ObjectDescriptionHere",
      "persistent": true,
      "relationships": [
        "type": "rel_type",
        "targets": "["object1","object2",...]
    . up to 100 objects
Parameter Required or Optional Description



A text string describing the object. A label can contain only alphanumeric characters, hyphens, and underscores. It can’t contain unicode characters and spaces.

In an orchestration, the label for each object must be unique.

Maximum length: 256 characters.



The type of object that you want to create.

Specify one of the following object types.

  • Acl

  • Backup

  • BackupConfiguration

  • Instance

  • IpAddressAssociation

  • IpAddressPrefixSet

  • IpAddressReservation

  • IpNetwork

  • IpNetworkExchange

  • IPReservation

  • OSSContainer

  • Restore

  • Route

  • SecApplication

  • SecIPList

  • SecList

  • SecRule

  • SecurityProtocol

  • SecurityRule

  • SSHKey

  • StorageAttachment

  • StorageSnapshot

  • StorageVolume

  • VirtualNicSet

For a brief description of each object type, see Object Types in Orchestrations v2.



The parameters specific to each object type.

See Orchestration v2 Attributes Specific to Each Object Type.



The four-part name of the object (/Compute-identity_domain/user/orchestration/object

If you don’t specify a name for this object, the name is generated automatically.

Object names can contain only alphanumeric characters, hyphens, underscores, and periods. Object names are case-sensitive.

When you specify the object name, ensure that an object of the same type and with the same name doesn’t already exist. If such a object already exists, then another object of the same type and with the same name won’t be created and the existing object won’t be updated.



The three-part name of the orchestration (/Compute-identity_domain/user/orchestration_name) to which the object belongs.



Specifies the desired state of an object. This allows you to manage the state of an object independently from the state of the orchestration. Specify one of the following:

  • inherit: The default. The desired state of the object is the same as the desired state of the orchestration. Note that you can’t specify states such as active, inactive, or suspend at the object level. These states must be inherited from the orchestration’s desired state.

  • delete: The object definition is removed from the orchestration JSON and the underlying object that was created by this orchestration is also deleted.



A text string describing the object.



Specifies whether the object should persist when the orchestration is suspended. Specify one of the following:

  • true: The object persists when the orchestration is suspended.

  • false: The object is deleted when the orchestration is suspended.

By default, persistent is set to false. It is recommended that you specify true for storage volumes and other critical objects.

Persistence applies only when you’re suspending an orchestration. When you terminate an orchestration, all the objects defined in it are deleted.



The relationship between the objects that are created by this orchestration.

The depends relationship indicates that the specified target objects must be created first. For example, if you define two instances – instance1 and instance2 – in an orchestration and you want instance1 to be created first, then in the relationships attribute of instance2, specify that it depends on instance1.

"relationships": [
    "type": "depends",
    "targets": ["instance1"]

Note that when recovering from a failure, the orchestration doesn’t consider object relationships. Orchestrations v2 use object references to recover interdependent objects to a healthy state. See Object References and Relationships.