Chapter 35. Service Objects

We saw in Chapter 26 that provisioning operations always include a request object, and a task object that links to source and destination objects.

When we provision a virtual machine 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 chapter 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:

• We are using CloudForms 3.2.

• 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 in Figure 35-1 (some objects and links/relationships have been omitted for clarity).

Figure 35-1. Service object relationship

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']

From here we can access any of the other objects by following associations.

Source

The source is 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

The destination is 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

The service template provisioning request is 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 backlinks to this request object.

Child miq_request_task

The child miq_request_task is accessed from:

$evm.root['service_template_provision_task'].miq_request_tasks.each do |child|

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., virtual machine) that makes up the final service, so for a service bundle containing three VMs, there will be three child miq_request_tasks.

Service resource

The service resource is accessed from:

child_task.service_resource

This ServiceResource object stores details about this particular service item and its place in the overall service structure. A 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 WebUI for a multiitem service bundle (see Figure 35-2).

Figure 35-2. Start and stop actions and delays in a multiitem bundle

The service resource has a relationship to the ServiceTemplate object via child_task.service_resource.service_template.

Source

The source is 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

The destination is 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

The grandchild miq_request_task is accessed from:

child_task.miq_request_tasks.each do |grandchild_task|

This is an MiqProvisionVmware miq_request_task object (renamed to ManageIQ_Providers_Vmware_InfraManager_Provision in CloudForms 4.0) and is the task object that represents the creation of the VM. This is exactly the same as the task object described in Chapter 26.

It is the grandchild miq_request_task that contains the options hash for the VM to be provisioned; this is 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

The source is accessed from:

grandchild_task.source

This is the TemplateVmware object (renamed to ManageIQ_Providers_Vmware_InfraManager_Template in CloudForms 4.0) that represents the VMware template that the new VM will be cloned from.

Destination

The destination is accessed from:

grandchild_task.destination

or:

grandchild_task.vm

This is the VmVmware object (renamed to ManageIQ_Providers_Vmware_InfraManager_Vm in CloudForms 4.0) that represents the newly created VM. This VM object has an association service that links to the newly created service object.