Cloud Management Troubleshooting - Policies
Introduction - How policies work
In the Cloud User Portal UI, for example, when you are provisioning a cloud resource such as creating a VM, the following fields can be displayed:
In Cloud Management, policies will be executed if a set of conditions are met. If these conditions are met, rule actions defined in configured rules will be executed. The following rule actions are available:
- Property Override - This action will set the value of a given parameter of the operation, for example, if the user wants to override the Lease End Date parameter.
- Execute a script - Execute a ServiceNow script on the instance. All the operation parameters are available as inputs to the script, for example: Stack Name can be accessed through formData.StackName.
- Abort Process - This action will stop the workflow that drives the overall orchestration (Blueprint Request).
The "Blueprint Request" workflow governs resource provisioning and should not be edited. When an item is provisioned, Policies are processed at a given workflow activity based on the Policy Trigger the user configured.
To create a new policy, navigate to Cloud Management > Policy.
In Kingston navigate to Cloud Admin Portal > Govern > Policies.
Notice the Policy Triggers available and their corresponding workflow activities for the following triggers:
- Catalog item request start
- Blueprint provision
- Blueprint provision approval
- Catalog item request end
After the policy is named and a trigger is defined, you can configure actions (property override, execute a script or abort the workflow).
The overall logical structure of a policy
A policy is executed on a trigger for a set of rules. These rules contain a set of conditions. If the conditions are met, actions are executed, for example, property override or execute script. A trigger can have 1 to n policies but the recommendation is to have only one trigger per policy because policies are executed one at a time. A policy can have 1 – n rules and each rule can have 0 to n conditions. Based on the true value of conditions, actions will be executed (1 – n actions).
You can optionally configure a policy group if you want to group a set of policies based on a particular trigger.
The first step in troubleshooting policy issues is to go to Cloud Root Cause Analysis.
In Kingston, Root Cause Analysis Dashboard can be found by navigating to Cloud Admin Portal > Operate.
You can also go straight to the filter navigator and type sn_cmp_cloud_trail.list.
From Cloud Root Cause Analysis you can check the policy steps and get more information by drilling into Cloud Orchestration Trail. For more in-depth troubleshooting you can go to sn_cmp_cloud_trail.list and filter the Step.Name is Apply Policy.
If you open and inspect the record, you can look at the payload in the Message Details and by using a JSON parser you can troubleshoot it by analyzing the following:
object -> rules -> index -> input -> formData
or, for modified fields: object -> rules -> index -> modified -> formData
If you are running script, you can modify attributes only in the formData .
The attributes available when you are writing a script are the ones under input, as follows:
entityId is: Catalog ID, Catalog Item ID, Group Item ID, Resource ID
You can use any online JSON viewing tool such as http://jsoneditoronline.org/ to easily see the relevant attributes.