We discovered in Approval and [quota-management] 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 learnt 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 when we provision a virtual machine from a service catalog.
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.
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.
The schema for the ServiceProvisionRequestApproval/Default state machine is shown in 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.
Quota checking for a service provision request in ManageIQ Capablanca uses the same consolidated quota mechanism as described in [quota-management].
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.
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 customise the behaviour if we wish.
In practice we rarely need to customise these workflows. As virtualisation 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 behavour of auto-approval of all service requests is valid in most situations.