DON’T FORGET BACKUPS !!
In my previous post “Approval Policies – Don’t lock yourself out of a request”, I warned about the ability to lock yourself out of an approval policy. Or rather out of a request affected by one.
This happens when you add an Active Directory User-group to the approvers, whilst the members were added to the group AFTER the request has been made.
Adding the users after the request has been made will not have an affect on the request already been made.
When you create a request, a work item is being created with all the relevant information, such as blueprint, requestor, tenant and so on.
Any changes made after the work item has been issued, won’t affect already issued work items. Same applies to changes to blueprints.
Any changes to Blueprints, such as resource allowances etc., will not affect any already deployed virtual machines.
You’d have to either re-create the VM or unregister the VM from vRA and re-import the VM so blueprint changes are being populated.
Anyway, back to stuck Approval Policies. Here an example:
Here Request #176 is Pending Approval
In the Approval Policy I specified the AD Group vRA-Approvers as sole approvers.
Which ‘accidentally’ has no one in it
I now add myself (cloud-admin) to it and re-sync AD.
Yet I am unable to approve or reject this request.
Now when I check the work item of this request – you can see it includes all the relevant information to process this request once approved
So how can you get rid of it again ?
I previously created an article which explains how you can remove a stuck request, however, whilst this would work for the request itself, it won’t work for the approval.
All you’d accomplish is removing the request from the approval. As a result you’d get an error when trying to view the request, making matters rather worse.
You will still need Postgres in order to fix this though.
SSH to your vRA appliance and login with root.
Now open Postgres as user postgres
/opt/vmware/vpostgres/9.4/bin/psql -U postgres
Change to the vRA database
\c vcac
As mentioned previously, the request we want to delete is request number #176, but the approval number is #10
Check the details of workitem #10 to ensure this is the correct approval in question
select * from work_item where workitemnumber =10;
If you cannot really read anything because it is all jumbled around
Use
\x
to enable the expanded view
And check again
Check if the above request matches the approval
If you have more requests during the same time, you might have to look for other proof – like description, requestor, blueprint etc.
I trust that the workitem #10 matches my stuck approval #10
Easiest solution is to cancel the work item. Trying to remove request and approval from the DB can be lengthly – and as mentioned, might not work at all 🙂
So here I cancel workitem #10
update work_item set state=’CANCELLED’ where workitemnumber = 10;
After a UI refresh you can see that the stuck approval is gone (here it stops at #9)
