Object References and Relationships

Object References

When you define an object in an orchestration, you can create dependencies with other objects by using references. With references, you can link an object to another using just the label of the target object. For example, you can reference the name of a storage volume from a storage attachment object using the format {{volume_label:name}}.

When recovering an object from a failure, Compute Classic recovers all the referenced objects automatically.

In the following example, the StorageAttachment object references the name attribute of an instance and the name attribute of a storage volume that’s to be attached to the instance.

{
	"description": "a storage attachment object with references",
	"label": "attachment_object",
	"type": "StorageAttachment",
	"template": {
		"index": 1,
		"instance_name": "{{myInstance1:name}}",
		"storage_volume_name": "{{myVolume1:name}}"
	}
}
  • myInstance1 is the label of the instance object.

  • myVolume1 is the label of the storage volume object.

Object Relationships

You can use the relationships attribute of an object to specify other related objects that must be created first.

Ensure that you don’t create a relationship between a persistent and a nonpersistent object. A persistent object can be in a relationship only with another persistent object.

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:

When recovering from a failure, orchestrations don’t consider object relationships. So in the preceding example, if instance2 fails, then the orchestration re-creates it, but it doesn’t ensure first that instance1 is available. To ensure that dependent objects are re-created, use object referencing.

For more complex scenarios, you can define multiple relationships.

For example, to ensure that instance4 starts after instance1, instance2, and instance3 are started, specify the following in the relationships attribute of instance4.

"relationships": [
  {
    "type": "depends",
    "targets": ["instance1","instance2","instance3"]
  }
]

If all the related instances fail, then the orchestration will re-create them. But when re-creating instance4, the orchestration does not check whether the other instances exist.