Policies are used to
define the actions to be executed against a service item instance when certain
conditions are met. A typical example is that when a virtual machine is
approaching its expiration date, an automatic notification is sent to its owner
as a reminder. Other policy actions may include triggering a service request to
process the service item, or logging an alert for administrators, or preventing
a new service request from being submitted. Policies may be defined to be
specific to an account or generic to all accounts.
The policies are
categorized into four types, namely: Capacity, Quota, Timebound, and
Event-based policies.
Capacity- When
you define a capacity policy, you enforce a limit for the usage of an
attribute. An action is performed when the usage exceeds the defined limit.
Before you define a capacity policy, you must define the service item attribute
that has to be managed by the capacity policy. See
Managing
Service Item Attributes.
When you configure a
service item attribute as a capacity attribute, the following attributes are
generated to be used for capacity management:
-
- Used{AttributeName}, for
example, "UsedVCPU" - Used by the application to track how much of
the capacity is used. This value is not user-modifiable.
- Req{AttributeName}, for
example, "ReqVCPU" - Used by service designer to pass the capacity
change required in service requests or update operations in service item APIs.
You can use capacity
policy to track your own resource consumption such as type of storage network,
usage of each of the elements in the network, and take necessary actions
accordingly if you are a service provider.
Examples of Capacity
policy:
-
- You may define a policy that
sends an email when the capacity of the storage area network reaches 80% of the
capacity.
- Quota - The quota policy
is executed when an Item Attribute reaches the threshold% of maximum value.
Each quota policy is specific to an account and cannot be applied to multiple
accounts. Before you define a quota policy you must:
- Define the service item
attribute that has to be managed by the quota policy. See
Managing
Service Item Attributes.
- Ensure a quota is already
defined in an agreement that corresponds to the account being referenced in the
quota policy. This is maintained under Demand Management > Agreement. The service item that is
subject to quota management should already be included in the agreement quota
with an appropriate aggregate method (see
Configuring
Billing Rates Based on Usage for more information).
- When specifying a quota
policy, select the appropriate aggregate method that tracks the quota
consumption. The “Sum” aggregate method manages the quota based on the sum of a
specific attribute consumed by all service item instances (for example, sum of
disk size for all datastores owned by the account). The “Count” aggregate
method manages the quota simply based on the service item count (for example,
total number of virtual machines owned by the account).
Examples of Quota Policy:
-
- A policy that sends an email
when the count of the virtual machine for an account reaches 70% of the quota.
- A policy that orders a
service when the storage of the virtual disk for an account reaches 75% of the
quota.
-
Timebound -
This policy is executed when the date attributes of the service item reaches or
exceeds the defined value. A poller evaluates the time bound policies at a time
interval of every 30 minutes by default and performs actions as necessary. You
can enable/disable the poller in the support.properties file. For more
information about configuration files, see
Cisco Prime Service Catalog
Administration and Operations Guide.
Examples of
Timebound Policy:
- A policy that sends an email
to the owner of a software subscription one month before the subscription
expiration to remind the person to renew the subscription.
- A policy that revokes the
subscription to a software on the lease expiration date.
To see the example of
how you can terminate a lease using this policy, see
Configuring
Time-Bound Policies.
To define this policy
on a service item, there must be at least one service item attribute of
attribute type “DateTime”.
-
Event based
- Event based policies support three conditions:
- An action is triggered when
a service item attribute reaches a particular value.
- An action is triggered when
a service item attribute reaches a particular value, or when the attribute
value has been modified.
- An action is triggered when
the service item attribute satisfies certain conditions. You can define a
condition for a service item attribute, to determine if the particular value
'is equal to', 'is not equal to', 'contains' or 'does not contain' based on the
options you can select from the logical operator drop-down list to trigger an
event. You can either enter the value for the service item attribute or select
from the namespace icon. You can add multiple conditions and more than one
service item attribute for a particular value.
Examples of Event-based
Policy:
-
- Perform action when
attribute is updated - Create a policy that records a policy alert when the
status of the virtual machine becomes offline.
- Perform action when
conditions are met - Create a policy with conditions that record a policy alert
when the RAM value has reached its maximum limit and sends an email when the
status of production HANA database goes offline and the backup server is
active.
Policy Actions
One or more actions
may be performed when the policy condition is satisfied. The predefined actions
are:
- Stop submission- Prohibit
the requester from making another request to consume the service item. This
action is not applicable to the time bound policy type.
- Order Service- Spawn a
request for a service within the catalog to allow a supporting operation to
take place. If you choose to order a service when a condition is satisfied,
then you must also:
- Select a service from a list
of existing service definitions
- Specify the values to be
passed to the service form. Any namespaces referenced will be resolved to the
actual values based on the context when the service is ordered. For more
information, see
Namespace
Usage.
- Send email- If you choose to
send an email when the policy condition is satisfied you must also select an
email template from the email template drop-down list. You can define email
templates in
Administration
> Notifications, just like any other email templates used for service
delivery.
- Policy alert- Log the policy
trigger occurrence that serves as an audit trail for administrators to review.
If you send a policy alert to the application you must also provide a
descriptive message for the alert. You can also use namespaces to specify the
service item attribute that will be resolved when the message is displayed.
To view the list of
policy alerts when the condition is satisfied, add the Policy Alert portlet to
any existing portal pages in Service Portal module. Choose
Service Portal>
Edit Page > Add Content > Reserved portlets. Click
Policy alerts
check box. Policy alerts are logged for Policy alert and Order Service actions.