Disclaimer: These are my notes from studying for the 3V0-31.18 exam. If something doesn’t make sense, please feel free to reach out.
The main goal for the whole of section 3 is to understand how to build governance into your vRA installation.
Objective 3.2 – Implement a Governance Model that Maps to Given Business Needs
This is very much around approval policies so we need to think about how to define a policy & how to consume said policy.
Define a policy:
- Policy Type
Consume a policy:
- Catalogue item
- Resource action
Go to Administration, Approval Policies and hit the New button. You’ll be presented with the policy type box. These are fairly self explanatory but in essence they’re split into two categories – Resource Action & Catalogue Item – with the resource type after. In this case I’m firing up a policy for Catalog Item. Give your policy a name & set the status.
Quick note on status. Active & assigned policies cannot be edited to preserve them for auditing. Recommendation if you need to change a policy is to clone the policy & create a new policy. Again to preserve the integrity of the auditing.
Underneath this you can see two tabs, one to define ‘Pre’ approvals & the other to define ‘post’ approvals. The difference between these is:
- PRE: Approval is required before the item is provisioned
- POST: Approval is required before the item is presented back to the user
Once you’ve made the decision on when you need your approval to take place, you’ll need to decide if you want to have all requests approved (which may defeat the purpose of building a cloud platform) or if you wish to have items approved if they meet certain criteria such as cost or resource usage.
I’m configuring a fairly typical policy that will request approval before provisioning if a user is requesting more than xGB memory or if more than x CPUs are requested. When doing multiple conditions these can be configured in an AND/OR scenario. I’m doing an OR, so more than 2047MB memory OR more than/equal to 2 CPUs. (Lab environment values :-))
Your next step is to define the approvers. This can be any of the below:
- Specific Users/Groups (pretty self explanatory)
- Determine from request (I tend to use this to get the approval from the business group managers)
- Use an event subscription (Tend to be when the approval will come in from another workflow, Service Now for example)
In this example I’ve gone for the business group manager, and set to anyone can approve (a single approval is enough for this example).
Next on the System Properties tab you can set the items that can be changed by the approver. So I could put CPU & memory on this to allow the approver to drop them down to under the threshold if they chose. I try to avoid this if possible, most people have a reason they’ve requested x, y & z. A conversation tends to be the best way to resolve these things! 🙂
You can also add custom properties to the approval, I’m not at this stage.
Once you’ve created the approval, you can then add another level. This doesn’t take effect until the first level has been approved. Using our example here, the manager approves of the additional resources usage but this means that finance need to approve the additional spend. For this example we’ll leave it at a single level.
To enable the approval policy against specified items, edit the entitlement where you need it to take effect.
An approval policy can only be set against a catalogue item or a resource action, not against a service. When you first add the policy to the item, the drop down will only show you policies that are of the same type, but you can change to show all to see all the policies. Often you find that the blueprints you’ve created are composite blueprints and you want to configure an approval policy against say, a virtual machine.
That’s the way to create and consume an approval policy, now onwards to actually approving!
Objective 3.3 – Configure notifications to allow approvers to respond via email
This is split up into two parts:
- Configure the mail server (inbound & outbound)
- Activate/Deactivate notification scenarios
The email side of approvals is needed to remove some of the friction from the approval process. Instead of relying on an approver logging into the vRA portal and actioning the approval, they receive an email from which they can click either an approve link or a reject link. This generates an email to the inbound mailbox, which vRA will process. Below is how to configure, although it won’t work in my lab as I haven’t got access to a mail server (Note to self, configure mail server…)
Configure Mail Server
Go to Administration, Notifications, Email Servers and hit the Add button. vRA will then ask if you want to configure the inbound or outbound mail server. The settings underneath are pretty much what you’d expect. I wouldn’t have the inbound mailbox as an account that users can login to, just to ensure that any approvals don’t go MIA.
Once the mail server is configured, click on Scenarios. You’ll notice that they’re all active by default, you can go through and Suspend the notifications that you don’t want to send out. Suspending certain notifications is just as valid as ensuring they are active.