You can manually upload and start orchestrations or you can use the REST API to create a orchestration and start it. In both cases you will need to understand how to craft a correct JSON file that will create your storage volume for you.
Storage volume JSON
The below JSON message shows the entire orchestration file used to create a storage volume named oplantest1boot.
{
"name": "/Compute-demoname/demouser@demoname.com/oplan_test1",
"description": "oplan test 1",
"relationships": [],
"oplans": [
{
"label": "My storage volumes",
"obj_type": "storage/volume",
"objects": [{
"name": "/Compute-demoname/demouser@demoname.com/oplantest1boot",
"bootable": true,
"imagelist": "/oracle/public/OL_6.4_UEKR3_x86_64",
"properties": ["/oracle/public/storage/default"],
"size": "12884901888",
"description": "boot device for oplan test 1"
}]
}
]
}
The JSON file shown above can be broken down in two parts. We have the top-level attributes, top-level attributes contain the name and description of an orchestration, along with other information such as the relationship between objects defined in the orchestration, start and stop times for the orchestration, and the list of objects in the orchestration.
The top-level attributes construction will envelope one or more oplans (object plans). The oplan(s) are the description of the actual object or objects that will be created when the orchestration will be started.
Orchestration top level attributes
The top-level attributes part of the above example orchestration is shown below. As you can see we have removed the oplan for the storage creation to make it more readable.
{
"name": "/Compute-demoname/demouser@demoname.com/oplan_test1",
"description": "oplan test 1",
"relationships": [],
"oplans": [
{
...OPLAN(S)...
}
]
}
Orchestration attributes for storage volumes
The below shows the oplan which will create the actual storage volume. For readability we have shown this as a separate part outside of the context of the top level attribute.
{
"label": "My storage volumes",
"obj_type": "storage/volume",
"objects": [{
"name": "/Compute-demoname/demouser@demoname.com/oplantest1boot",
"bootable": true,
"imagelist": "/oracle/public/OL_6.4_UEKR3_x86_64",
"properties": ["/oracle/public/storage/default"],
"size": "12884901888",
"description": "boot device for oplan test 1"
}]
}
As you can see we have a number of attributes that are specified. The main attributes you can specify for every oplan (not only for storage) are:
- label
- A text string describing your object plan. This can be everything as long as it is not exceeding 256 characters.
- obj_type
- the obj_type attribute lets you define what type of objects will be created as part of this specific oplan. In our case we will create a storage volume which means we will have to use the "storage/volume" object type. For other object types you can refer to the Oracle documentation on this subject.
- objects
- Objects is the placeholder for an array of objects of the object type specified in the obj_type attribute. This means, if you need to create multiple storage objects you can all defined them within the object placeholder.
- ha_policy
- The ha_policy attribute is optional and not shown in the example above. You can state monitor as a value for this or leave it out. When the HA policy for an object is set to monitor, if the object goes to an error state or stops unexpectedly, the orchestration changes to the Error state. However, the object isn’t re-created automatically.
{
"name": "/Compute-demoname/demouser@demoname.com/oplantest1boot",
"bootable": true,
"imagelist": "/oracle/public/OL_6.4_UEKR3_x86_64",
"properties": ["/oracle/public/storage/default"],
"size": "12884901888",
"description": "boot device for oplan test 1"
}
As you can see we have a number of attributes that are specified in the above section of the JSON message. These are the primary required attributes when creating a storage volume.
- name
- name is used to state the name of your storage volume. It needs to be constructed in the following manner /compute-identity_domain/user/name to ensure it is fully compatible and will be placed in the right location.
- size
- Size can be given bytes, kilobytes, megabytes, gigabytes or terrabytes. The default is byets however every unit of measure can used by using an (uppercase or lowercase) identifyer like B, K, M, G or T. For example, to create a volume of size 10 gigabytes, you can specify 10G, or 10240M, or 10485760K, and so on. Where it need to be in the allowed range between from 1 GB and 2 TB, in increments of 1 GB.
- properties
- The properties section let you select the type of storage that you require. Currently the options available are standard and low latency storage. In case you are able to work with standard storage you can use /oracle/public/storage/default as a string value. In case you need low latency and high IOPS you can use /oracle/public/storage/latency as a string value.
- description
- A descriptive text string describing your storage volume.
- bootable
- bootable is optional and wil indicate if this storage volume should be considered as the boot volume of a machine. The default is false and false will be used if the attribute is not specified. If bootable is set to true you have to provide the attribute imagelist and imagelist_entry.
- imagelist
- Required when bootable is set to True. Name of machine image to extract onto this volume when created. In our example case this is a publicly available image from the images created by Oracle /oracle/public/OL_6.4_UEKR3_x86_64
- imagelist_entry
- the imagelist_entry attribute is used to specify the version of the image from the imagelist you want to use. The default value when not provided is 1. Do note, some Oracle Documentation states imagelistentry without the underscore, this is the wrong notation and you should use imagelist_entry (with the underscore)
- tags
- tags is used to provide tags to the storage volume which can be used for administrative purposes.
Additionally you will have the option to use a snapshot to create an image. This can be used in a process where you want to clone machines using a storage snapshot. In this case you will have to use an existing snapshot and provide the following attributes to ensure the snapshot is restored in the new storage volume.
- snapshot
- Multipart name of the storage snapshot from which you want to restore or clone the storage volume.
- snapshot_id
- ID of the parent snapshot from which you want to restore a storage volume.
- snapshot_account
- Account of the parent snapshot from which you want to restore a storage volume.
Using an orchestration
The above examples show you how you can create an orchestration for creating a storage volume. In most real-world cases you will mix the creation of a storage volume with the creation of other objects For example an instance where you will attach the storage at.
However, as soon as you have a valid JSON payload you can upload this to the Oracle Public Cloud via the web interface or using an API. Orchestrations that have been uploaded to the cloud can be started and when completed they will result in the objects (storage volume in this case) to be created.
Having the option to quickly create a JSON file as payload and send this to the Oracle Public Cloud highly supports the integration with existing automation tooling and helps in building automatic deployment and scaling solutions.
No comments:
Post a Comment