By using policy-based leases, you reduce the need to intervene manually to reclaim resources. You define lease policies so that you can control the amount of time that a deployment is available to your users. The lease policy use cases in this procedure provide a beginning point for learning about and implementing policies for your organization.
If you do not have any lease policies defined, then the deployments never expire. To reclaim the resources, you must manually destroy the deployments.
When does a lease policy go into effect
- If the policy scope is Organization, then all the deployments in your organization are managed based on the defined policies.
- If the policy scope is a project, then the deployments that are associated with that project are managed based on the defined lease. Other projects are not affected.
When are lease policies applied
- Create or update a lease policy. After lease policies are applied, they continuously evaluate the deployments in the background to ensure that they are in compliance with the defined leases.
- Request a catalog item in Service Broker or a cloud template in Cloud Assembly. The maximum lease and maximum total lease values go into effect when the deployment is created.
- Onboard workloads or resources in Cloud Assembly so that you can manage them using Service Broker, Cloud Assembly, or Code Stream.
Lease-specific options
- Maximum Lease (days). The number of days that the deployment resources are active without being renewed. If they are not renewed, the lease expires and the deployment is destroyed. If a grace period is specified, the user can renew the lease for up to the same number of days that the lease has been active.
- Maximum Total Lease (days). The combined total number of days that the deployment can be active, including lease renewals. Each renewal cannot exceed the maximum lease, and the cumulative renewal value cannot exceed the maximum total lease. After the total lease is reached, the deployment is destroyed and the resources within that deployment are reclaimed.
- Grace period (days). The number of days the user has to renew an expired lease before the deployment is destroyed. The grace period is not included in the total lease days. If you don't define a grace period, it defaults to 1 day.
What happens when I update an existing lease policy
You can increase the maximum lease, the maximum total lease, and the grace period of your lease policies. The updated policy is applied to new deployments only.
Note that increasing the policy parameters does not extend the expiry date of existing deployments. Existing deployments expire on the same date as originally scheduled.
If you decrease the lease values, however, the deployment expiry date is affected and existing deployments expire earlier than originally scheduled.
What happens when a deployment expires
When a deployment is about to expire, the deploying user receives an email notification. If the user doesn't extend the lease, the deployment expires and is scheduled for deletion.
Expired virtual machines are powered off within several minutes after expiry. Unless the lease is extended, a powered-off machine can't be powered back on in vRealize Automation. The machine can be powered back on manually in the original environment, in which case vRealize Automation registers the machine as powered on. Even though the deployment is already expired, the machine is not automatically powered off for a second time until the grace period of the lease policy is elapsed and the deployment is deleted.
Procedure
In this use case, there are three policy definitions that illustrate how you can construct policies and the results when they are enforced. The last policy is not enforced, but the reasons are provided in the scenario results.
- Select .
- Configure Lease Policy 1.
As an administrator, you want to control costs by limiting the starting lease time for all deployments to 30 days, with the option to renew the lease for a total of 90 days.
- Define when the policy is valid.
Setting Sample Value Scope Organization This policy is applied to everyone in your organization.
Criteria None Enforcement type Soft This enforcement type allows you to create other policies related to this lease that override this policy.
- Define the lease.
Setting Sample Value Maximum lease (days) 30 Maximum total lease (days) 90 Grace period (days) 10
In this scenario, the deployment is shut down after 30 days and an email is sent to the user. During the grace period, the user extends the lease by 30 days. After the lease expires again, the user renews it for another 30 days. At the end of the third extension, the lease reaches the maximum total lease period of 90 active days and the user cannot extend it anymore. The deployment is shut down and destroyed 10 days later.
- Define when the policy is valid.
- Configure Lease Policy 2.
As an administrator, you want to control costs by limiting the lease time on an expensive template to two weeks. For this example, the template name is Multi-tier 5 machine with LB.
- Define when the policy is valid.
Setting Sample Value Scope Project MT5 This policy applied to deployments associated with this project.
Criteria Cloud Template equals Multi-tier 5 machine with LB
Based on this criteria expression, only deployments for the referenced template are considered for policy enforcement.
Enforcement type Soft This soft enforcement still overrides the organization policy of 90 days in Policy 1 because the values are more meaningful at the project level.
- Define the lease policy.
Setting Sample Value Maximum lease (days) 14 Maximum total lease (days) 28 Grace period (days) 3
In this scenario, both policies are applied, but Policy 2 takes precedence over Policy 1 because it is more specific. When applied, the deployment is shut down after 14 days. If the user does not extend the lease, it is destroyed three days later. If the user extends the lease for up to another 14 days, the deployment is shut down at the end of the second extension and it is destroyed three days later.
- Define when the policy is valid.
- Review the configuration of Lease Policy 3.
As a project manager, you realize that one of your developers is working on a complex application. The developer requires the Multi-tier 5 Machines with LB template and another template, Distributed Database Across Clouds, but for a longer lease than defined in Policy 2.
Unless you understand how the policies are processed based on how they are defined, you might encounter unexpected results. Policy 3 is an example of how processing and precedence affect the result.
This policy, as provided, will not be enforced. This example provides an opportunity for you to see how leases are applied and enforced when there is more than one that applies.
- Define when the policy is valid.
Setting Sample Value Scope Project MT5 This policy is applied to deployments in this project.
Criteria (Cloud Template equals Multi-tier five machine with LB OR Catalog Item equals Distributed Database Across Clouds) AND Created By equals [email protected]You use Catalog Item because it is a non- Cloud Assembly template.
Enforcement type Soft This soft enforcement still overrides the organization policy of 90 days in policy 1 because the values are more meaningful at the project level.
- Define the lease policy.
Setting Sample Value Maximum lease (days) 21 Maximum total lease (days) 50 Grace period (days) 3 In this scenario, Lease Policy 2 is applied, not Lease Policy 3.- Lease 3 has a lease time that is less than or equal to 21 days, and the policy is applied. Lease 2 has a lease time that is less than or equal to 14 days, and the policy is applied.
- Lease 2 is applicable and it does not violate the lease 3 policy. But, lease 2 is more restrictive, so it takes precedence. Lease policy 2 is more restrictive because it is for a shorter period of time.
- When both lease definitions are true and applicable, the more restrictive policy is the one that is enforced.
- Define when the policy is valid.
- To resolve the unexpected behavior in Lease Policy 3, you can implement one of the following solutions.
- To ensure that you can provide Jan with the needed policy, change the enforcement type to hard.
- Alternatively, you could create a new project with access to the same resources, and then create Lease Policy 3 for that project. While this solution isolates the working policy, you must maintain a parallel project. The effort needed to set up and maintain the content sources, content sharing, and so on, are time consuming and subject to error.
What to do next
- For more examples of how the lease policies are processed and enforced, see How are Service Broker policies processed.
- Configure policies that are relevant to your organizations and projects. If you are just getting started with lease policies, begin with one lease policy at the organization level.
- To send an email to the deploying user, configure the email server for notifications. See Add an email server in Service Broker to send notifications.
- If you use vRealize Orchestrator, you can manage expired deployments and their resources by using extensibility subscriptions. See Using extensibility subscriptions to manage deployment expiry.
