Comparing Orchestrations v1 and Orchestrations v2

An orchestration defines the attributes and interdependencies of a collection of compute, networking, and storage resources in Compute Classic. You can use orchestrations to automate the provisioning and lifecycle operations of an entire virtual compute topology.

In earlier releases of Compute Classic, you could use orchestrations v1 to create and manage resources. From release 17.1.6 onwards, you can also create and manage resources using orchestrations v2. With orchestrations v2 you can take advantage of several key enhancements that allow you greater flexibility in referencing and managing resources.

Note:

You shouldn’t try to use or manage resources created using orchestrations v1 by referencing them in orchestrations v2, or vice versa.

There are some similarities and some key differences between orchestrations v1 and orchestrations v2.

Task Orchestrations v1 Orchestrations v2
Creating an orchestration Create your orchestration in a JSON file. Your orchestration can contain all the objects you want to create, or can reference nested orchestrations or objects created by other means. See Building Your First Orchestration v1. Create your orchestration in a JSON file. It is recommended that you create orchestrations that are entirely self-contained. Each orchestration should contain all the objects that you want to create, along with any objects referenced by those objects. The only external objects that an orchestration should reference are shared objects such as security lists that have been created earlier, or Oracle-provided resources such as images or shapes. See Building Your First Orchestration v2.
Creating objects in an orchestration See Object Types in an Orchestration for a list of objects that you can create using an orchestration. In addition to the objects that you can create using orchestrations v1, using orchestrations v2 you can also create storage snapshots and scheduled storage volume backups, restore storage volumes from scheduled backups, and add SSH keys. See Object Types in Orchestrations v2 for a list of objects that you can create using orchestrations v2.
Updating objects in a running orchestration You can add or remove oplans when an orchestration is running. However, you must stop an orchestration if you want to update objects. See Updating an Orchestration v1. You can add or delete objects in an orchestration when the orchestration is running. You can also update objects to modify certain attributes. See Updating an Orchestration v2.
Managing orchestrated objects individually You can use master orchestrations to reference multiple individual orchestrations within a single orchestration. This enables you to synchronize starting and stopping multiple orchestrations. However, when required, you can manage each of the nested orchestrations separately. This way you can, for example, delete instances defined in one orchestration, while retaining storage volumes defined in another orchestration. See About Nested Orchestrations. You can use object persistence to specify objects that should not be deleted when the orchestration is suspended. For example, you can specify persistence for some instances and all storage volumes in an orchestration. Suspending the orchestration deletes nonpersistent objects, while persistent objects are preserved. To delete all objects, terminate the orchestration. See Object Persistence in Orchestrations v2.
Defining dependencies between objects Relationships determine the sequence in which objects are created. You can define a one-on-one relationships either between different object plans, or between different instances. You can use relationships in a master orchestration to control the sequence in which a series of nested orchestrations is started. See Relationships Between Object Plans. You define associations between objects using object referencing. Unlike in orchestrations v1, in orchestrations v2 all the objects associated with a given object must be created in the same orchestration. This allows the orchestration to track the status of all referenced objects.

You can use relationships to determine the sequence in which objects are created. However, relationships shouldn’t be used to create dependencies, they should be used only to establish the sequence in which resources must be created. For dependencies, use references. See Object References and Relationships.

Re-creating an object when it stops unexpectedly When you specify the high availability policy for an instance as active, if the instance stops unexpectedly, it is re-created automatically. See About High-Availability Policies in an Orchestration. Failure recovery is implemented automatically for all objects. If any object fails unexpectedly, it is re-created automatically along with any objects that reference the failed object. See Recovering Failed Objects in Orchestrations v2.
Uploading and starting an orchestration You must upload your orchestration to Compute Classic and then start your orchestration to create the objects defined in the orchestration. When an orchestration has the desired state specified as active in its top-level attributes, then the orchestration starts automatically when it is successfully uploaded to Compute Classic.
Stopping an orchestration When you stop an orchestration, all objects created by that orchestration are deleted. You can either suspend or terminate an orchestration. When you suspend an orchestration, persistent objects aren’t deleted. When you terminate an orchestration, all objects are deleted.
Deleting an orchestration An orchestration must be stopped before it can be deleted. Stopping an orchestration causes objects to be deleted, but deleting an orchestration has no impact on objects that are defined in the orchestration. You can delete an orchestration when it is in the Ready, Suspended, Stopped or Error state. Any objects created by the orchestration are deleted when the orchestration is deleted.