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.
Lease policies are applied when you:
- 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.
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.
As you review the lease policies use case, you must also configure lease-specific options. The following descriptions provide a brief summary. Consult the signpost help for more information.
- 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.
Procedure
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.