Oracle Cloud master orchestrations

When deploying a new instance in the Oracle Compute Cloud Service you will notice this is driven by an orchestration. If you look at the orchestration tab you will notice it is not a single orchestration, it will contain out of 3 orchestrations. One to bundle them and actually two orchestrations that will create a tangible object. In our case the tangible object will be an instance and a storage object.

• Master orchestration which binds the two others together.
• Instance orchestration which will create the actual compute instance.
• Storage orchestration which will create the required storage volume. 

When working with orchestrations you have to remember that it is only the instruction set on how to create the actual end result. This means that, when you stop an orchestration the end result is not only stopped, it is also removed. When you start it again, the end result will be created again (from scratch).

In the below screenshot you can see 3 orchestrations which were used to create a compute instance named TESTBOX08 and the associated storage which was needed.

If we open the details of master orchestration we can see that this is actually a JSON file containing instructions on what to create.  In essence the master is used to bundle both the instance orchestration and the storage orchestration together and make it a single set of instructions.

As you can see in the above JSON used in the TESTBOX08_master orchestration there is a relationship defined in the master between TESTBOX08_storage and TESTBOX08_instance. The relationship is that you have a oplan named TESTBOX08_instance. This means that TESTBOX08_instance is the actual oplan, An object plan, or oplan, is the primary building block of an orchestration.

As you can see above and in the below example  this is how a  relationship within a oplan is defined.

{
 "oplan": ,
 "to_oplan": ,
 "type": "depends",
}

• oplan : the name of oplan1 
• to_oplan : Label of an oplan on which oplan1 depends
• type: Type of the relationship. It must be depends

for this plan that means that the instance depends on the storage, that also means that the storage will be created first and after that the instance as soon as you execute the master orchestration.

Be careful when stopping the master orchestration
When selecting the “stop” command on the TESTBOX08_master orchestration you will get a warning which looks like this:

"Orchestration "TESTBOX08_master" will be stopped. Stopping an orchestration will destroy all objects that were created using the orchestration. If you created instances using this orchestration, those instances will be deleted. If you provisioned storage volumes using this orchestration, those storage volumes will be deleted and all data stored on them will be lost. However, objects created outside this orchestration and merely referenced in this orchestration won't be deleted. At any time, you can re-create objects defined in this orchestration by starting it. Are you sure you want to stop this orchestration?"

As you can see in the above screenshot when you stop the master orchestration it will take some time before the associated orchestrations are stopped. In the screenshot below you can see how all 3 orchestrations are topped.

As you can see in the above screenshot, also the storage has stopped and remembering the warning this would mean that also the attached storage is stopped, which means it is removed. If you check the storage tab you will see that indeed the storage volume is no longer available.

Now, if I select “start” again on the master orchestration it will start executing the storage and the instance orchestration again. It will first start the storage as this is a pre-requisition for the instance. The issue with this way of working, and the risk is, that you have to be aware that your storage is really been removed and is created again from scratch.

Meaning, you will have a fresh environment again, everything you have ever done to the system is lost. Which might be very well something you like to do… however, if you goal was to stop the instance for some period of time and start it again at a later moment and continue working on it again this is not the right direction. In that case, the case you would like to “pause” your instance you have to stop the instance orchestration only, which is described in more detail in this blogpost.