A newly provisioned virtual machine consumes resources in a virtual infrastructure and potentially costs money in a public cloud. To control the consumption of resources and keep cloud costs in check, an approval stage is built into the virtual machine and instance provisioning workflow. By default, requests for single small virtual machines are auto-approved, but attempts to provision larger or multiple VMs are redirected for administrative approval.
This chapter describes the approval process and shows how we can fine-tune the approval thresholds based on the number of VMs, number of CPUs, or amount of memory in the request.
The provision request approval workflows are triggered by the request_created
and request_pending
events (see Figure 18-1).
The approval workflow for a virtual machine provision request is entered as a result of the /System/Policy/MiqProvisionRequest_created policy instance being run from a request_created
event. This policy instance contains two relationships, rel5
and rel6
.
The rel5
relationship performs a group profile lookup to read the value of the auto_approval_state_machine
attribute, which by default is ProvisionRequestApproval for an infrastructure virtual machine or cloud instance provision request.
The rel6
relationship runs the Default instance of this state machine (see Figure 18-2).
The Default instance of the ProvisionRequestApproval state machine has the field values shown in Figure 18-3.
This instance will auto-approve any VM provisioning request containing a single VM, but requests for more than this number will require explicit approval from an administrator or anyone in a group with the EvmRole-approver
(or equivalent) role.
The ProvisionRequestApproval state machine uses three methods to perform the validation.
The validate_request method is run from the On Entry field of the ValidateRequest
state. It checks the provisioning request against the schema max_
attributes, and if the request doesn’t exceed these maxima, the method exits cleanly. If the request does exceed the maxima, the method sets $evm.root['ae_result'] = 'error'
and a reason message before exiting.
The pending_request method is run from the On Error field of the ValidateRequest
state. This will be run if validate_request
exits with $evm.root['ae_result'] = 'error'
. The method is simple and merely raises a request_pending
event to trigger the MiqProvisionRequest_pending policy instance:
# Raise automation event: request_pending
$evm
.
root
[
"miq_request"
].
pending
The approve_request method is run from the On Entry field of the ApproveRequest
state. This will be run if validate_request exits cleanly. This is another very simple method that merely auto-approves the request:
# Auto-Approve request
$evm
.
log
(
"info"
,
"AUTO-APPROVING"
)
$evm
.
root
[
"miq_request"
].
approve
(
"admin"
,
"Auto-Approved"
)
If the ProvisionRequestApproval state machine doesn’t approve the request, it calls $evm.root["miq_request"].pending
, which triggers a request_pending
event. This is the trigger point into the second workflow through the MiqProvisionRequest_pending policy instance. This instance sends the emails to the requester and approver, notifying them that the provisioning request has not been auto-approved and needs manual approval.
We can copy the Default instance (including path) to our own domain and change or set any of the auto-approval schema attributes—that is, max_cpus
, max_vms
, max_memory
, or max_retirement_days
. Our new values will then be used when the next virtual machine is provisioned.
We can also override the auto-approval max_*
values stored in the ProvisionRequestApproval state machine on a per-template basis, by applying tags from one or more of the following tag categories to the template:
Tag category name | Tag category display name |
---|---|
|
Auto Approve - Max CPU |
|
Auto Approve - Max Memory |
|
Auto Approve - Max Retirement Days |
|
Auto Approve - Max VM |
If a template is tagged in such a way, then any VM provisioning request from that template will result in the template’s tag value being used for auto-approval considerations, rather than the attribute value from the schema.
There are four email instances with corresponding methods that are used to handle the sending of VM provisioning–related emails. The instances each have the attributes to_email_address
, from_email_address
, and signature
, which we can (and should) customize, after copying the instances to our own domain.
Three of the instances are approval-related. The to_email_address
value for the MiqProvisionRequest_Pending instance should contain the email address of a user (or mailing list) who is able to log in to the CloudForms appliance as an administrator or as a member of a group with the EvmRole-approver
role or equivalent (see Figure 18-4).
This chapter has shown how the virtual machine provisioning workflow allows for the approval stage to filter requests for large virtual machines while auto-approving small requests. This simplifies our life as virtualization administrators considerably. It allows us to retain a degree of control over large resource requests, even allowing us to define our own concept of large by setting schema attributes accordingly. It also allows us to delegate responsibility for small virtual machine requests to our standard users. Automation allows us to intervene for the exceptional cases yet auto-approve the ordinary “business as usual” requests.
We have also seen how we can fine-tune these approval thresholds on a per-template basis, so that if some of our users have valid reasons to provision large virtual machines from specific templates, we can allow them to without interruption.
The approval state machine and methods are a good example of the utility of defining thesholds as schema attributes or by using tags. We can customize the approval process to our own requirements without the need to write or edit any Ruby code.
18.191.237.201