Service Objects

We saw in VM Provisioning Objects that provisioning operations generally involve a request object, and a task object that links to source and destination objects.

When we provision a VM from a Service there are many more objects involved, because we are creating and referencing more items (creating both a service and potentially several new component VMs). When we provision from a service bundle, there will be several individual items to provision as part of the bundle. Even when we provision from a single service item however, the objects are structured as if we were provisioning a bundle containing only one item.

In this section we will look at some of the objects involved in provisioning a single VM from a Service Catalog Item. The objects are visible to us during the processing of the CatalogItemInitialization state machine.

For this example:

• The provider is VMware
• The service catalog item name that we've ordered from is called "Web Server"
• The service catalog item was created to clone from a VMware template called "rhel65-template"
• The new service name is "My New Service"
• The resulting service contains a VM called "test05".

We can use object_walker with the following @walk_association_whitelist to dump the objects:

{ "MiqAeServiceServiceTemplateProvisionTask" => ["source", "destination", "miq_request",
                                                "miq_request_tasks", "service_resource"],
"MiqAeServiceServiceTemplateProvisionRequest" => ["miq_request", "miq_request_tasks",
                                                "requester", "resource", "source"],
"MiqAeServiceServiceTemplate" => ["service_resources"],
"MiqAeServiceServiceResource" => ["resource", "service_template"],
"MiqAeServiceMiqProvisionVmware" => ['source', 'destination', 'miq_request'],
"MiqAeServiceMiqProvisionRequestTemplate" => ['source', 'destination'],
"MiqAeServiceVmVmware" => ['service'] }

We'll call the ObjectWalker instance from the post5 state/stage of the CatalogItemInitialization state machine.

Object Structure

We can illustrate the main object structure as follows (some objects and links/relationships have been omitted for clarity).

Service Template Provision Task

Our entry point into the object structure from $evm is to the main ServiceTemplateProvisionTask object. We access this from $evm.root['service_template_provision_task'], and from here we can access any of the other objects by following associations.

Source

Accessed from $evm.root['service_template_provision_task'].source, this is the ServiceTemplate object representing the service catalog item that has been ordered from.

Destination

Accessed from $evm.root['service_template_provision_task'].destination, this is the Service object representing the new service that will be created under My Services.

Service Template Provisioning Request

Accessed from $evm.root['service_template_provision_task'].miq_request, this is the initial ServiceTemplateProvisionRequest object that was created when we first ordered the new service. It is the request object for the entire service provision operation, including all VMs created as part of the service. This request object has associations to each of the task objects involved in assembling the service, and they in turn have back-links to this request object.

Child miq_request_task

Accessed from $evm.root['service_template_provision_task'].miq_request_tasks.each do |child_task|, this is also a ServiceTemplateProvisionTask object, and is the task object that represents the creation of an item for the new service.

There will be a child miq_request_task for each item (e.g. VM) that makes up the final service, so for a service bundle containing three VMs, there will be three child miq_request_tasks.

Service Resource

Accessed from child_task.service_resource, this ServiceResource object stores details about this particuar service item, and its place in the overall service structure.

The ServiceResource object has attributes such as...

service_resource.group_idx
service_resource.provision_index
...
service_resource.start_action
service_resource.start_delay
service_resource.stop_action
service_resource.stop_delay

These are generally zero or nil for a single-item service, but represent the values selected in the UI for a multi-item service bundle, i.e.

The Service Resource has a relationship to the ServiceTemplate object via child_task.service_resource.service_template.

Source

Accessed from child_task.source or child_task.service_resource.resource, this is the MiqProvisionRequestTemplate object that describes how the resulting VM will be created. The object looks very similar to a traditional VM provisioning request object, and contains an options hash populated from the dialog options that were selected when the service item was created (e.g. placement options, memory size, CPUs, etc).

Destination

Accessed from child_task.destination, this is the same Service object that is accessible from $evm.root['service_template_provision_task'].destination.

Grandchild miq_request_task

Accessed from child_task.miq_request_tasks.each do |grandchild_task|, this is an MiqProvisionVmware miq_request_task object, and is the task object that represents the creation of the VM. This is exactly the same as the Task Object described in VM Provisioning Objects.

It is the grandchild miq_request_task that contains the options hash for the VM to be provisioned; this being cloned from the options hash in the MiqProvisionRequestTemplate object. If we have a service dialog that prompts for properties affecting the provisioned VM (such as VM name, number of CPUs, memory, etc.), we must pass these dialog values to the grandchild task options hash.

Source

Accessed from grandchild_task.source, this is the TemplateVmware object that represents the VMware template that the new VM will be cloned from.

Destination

Accessed from grandchild_task.destination or grandchild_task.vm, this is the VmVmware object that represents the newly created VM. This VM object has an association .service that links to the newly created service object.