Chapter 32. Approval and Quota

We discovered in Chapters 18 and 19 that the virtual machine provisioning process includes an approval stage—to allow administrators to optionally approve large VM requests—and a quota-checking stage that enforces quotas applied to access-control groups or tenants. We also learned that these workflows were triggered from MiqProvisionRequest_created and MiqProvisionRequest_starting policy instances. When we create a virtual machine from a service catalog item, however, our request object is different, so we cannot rely on the existing approval and quota workflow triggers.

This chapter examines the approval and quota workflows for when we provision a virtual machine from a service catalog.

Triggering Events

When we order a new virtual machine from a service catalog, our request still needs to be approved and matched against our current tenant or group quota. As with virtual machine provisioning, each of the corresponding service provision workflows is triggered by the request_created and request_approved events, but the request object type is different. It is now a service_template_provision_request.

Approval

The approval process for a service provision request starts with the /System/Policy/ServiceTemplateProvisionRequest_created instance being run as a result of a request_created event. This instance contains two relationships, rel5 and rel6.

The rel5 relationship performs a service provisioning profile lookup to read the value of the auto_approval_state_machine attribute, which by default is ServiceProvisionRequestApproval for a service provision request.

The rel6 relationship runs the Default instance of this state machine (see Figure 32-1).

mcla 3201
Figure 32-1. ServiceProvisionRequestApproval state machine instance and methods

The schema for the ServiceProvisionRequestApproval/Default state machine is shown in Figure 32-2.

mcla 3202
Figure 32-2. ServiceProvisionRequestApproval/Default state machine schema

The methods pending_request and approve_request are the same as their counterparts for virtual machine provisioning approval. The default value of validate_request does nothing, so this state machine instance will auto-approve all service provisioning requests.

Customizing Approval

If universal auto-approval is not the required behavior, we can copy the ServiceProvisionRequestApproval/Default state machine methods to our own domain and edit them as necessary.

Quota

Quota checking for a service provision request in CloudForms 4.0 uses the same consolidated quota mechanism as described in Chapter 19.

The quota-checking process for a service provision request starts with the /System/Policy/ServiceTemplateProvisionRequest_starting instance being run as a result of a request_starting event. This policy instance runs the /System/CommonMethods/QuotaStateMachine/quota state machine from its rel2 relationship.

Email

The email instances that handle the sending of “approval denied/pending” and “quota exceeded” emails are in the RedHat domain but by default are not wired in to any policy instances.

If we wish to use them we can add a policy instance called /System/Policy/ServiceTemplateProvisionRequest_denied to our own domain. This should contain a relationship to the /Service/Provisioning/Email/ServiceTemplateProvisionRequest_Denied email instance in the RedHat domain.

Tip

We should ideally copy the Email/ServiceTemplateProvisionRequest_Denied instance into our own domain so that we can customize the from_email_address, to_email_address, and signature schema attributes.

Summary

We have seen how the approval and quota-checking mechanism for services mirrors that for virtual machines but uses different policy instances to trigger the workflows. The out-of-the-box approval workflow auto-approves all service requests, but we can copy the instance to our own domain to customize the behavior if we wish.

In practice we rarely need to customize these workflows. As virtualization administrators, when we provide a self-service catalog to our users, we generally accept the delegation of control and degree of responsibility that we pass to our users. This is, after all, one of the many benefits of implementing an Infrastructure as a Service cloud model. We almost certainly allocate quotas, but we rarely need to implement per-order approval as well. The default behavior of auto-approval of all service requests is valid in most situations.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.34.197