• Arun Nukula

"Change Lease" for Multiple Deployments

A Machine blueprint is a standalone blueprint that other architects can reuse as a component in application blueprints, and catalog administrators can include in catalog services.


You can specify settings that apply to the entire blueprint by using the Blueprint Properties page when you create the blueprint. After you create the blueprint, you can edit these settings on the Blueprint Properties page.


Settings on the General tab apply to the overall blueprint.

Lease (days) Minimum and Maximum

Enter a minimum and maximum value to allow users to choose from within a range of lease lengths. When the lease ends, the deployment is either destroyed or archived. If you do not specify a minimum or maximum value, the lease is set to never expire.

Enter lease information for your machines in your vRealize Automation blueprint, not in the source endpoint application. If you specify lease information in an external application, that lease information is not recognized or used in vRealize Automation.


Archive days You can specify an archival period to temporarily retain deployments instead of destroying deployments as soon as their lease expires. Specify 0 to destroy the deployment when its lease expires. The archive period begins on the day the lease expires. When the archive period ends, the deployment is destroyed. The default is 0.

In my example above I've set the minimum to 40 days and Maximum to 80 days


Propagate updates to existing deployments

Broadened minimum-maximum ranges for CPU, memory, or storage are pushed to active deployments that were provisioned from the blueprint. The new range must fully encompass the old range. For example, for an original minimum 32 and maximum 128 (32, 128), a change such as (16, 128) or (32, 256) or (2, 1000) can take effect upon reconfiguration or scale-out, but a change of (33, 512) or (4, 64) cannot.

The changes take effect upon the next reconfigure or scale-out action


When I deploy VM's out of this blueprint it would set these values to them as you can see in the screenshot



As you can see the values for these deployments is set to expiring in 1 month


If there are a handful of virtual machines then changing lease period to "Never Expires" is pretty easy


Remove the values of Lease (days) under blueprint properties and set Archive (days) to 0

Once done, click on OK, then Save and Finish to close the blueprint pane.

This will ensure that all future deployments are set to "Never Expires" as soon as they are deployed.


How about existing deployment's then?

One can browse to Deployment's tab and then click on "Change Lease", a day 2 action and then set it to "Never Expires"



How to execute "Change Lease" is present in this short recording below.


What if you have hundreds of deployment's and you would like to change them in one go?


Practically heading to every deployment and changing lease manually is an impossible task.


The only way available to change lease on multiple deployments in one go is to modify vRA's Postgres database tables


So let's provision a few virtual machines where the lease is set and we will use queries to make changes to these deployment's to set lease to never expire



As you can see in the screenshot above, I've made changes to Lease (days) to start with 1 and to go up to 6 days.


I have three deployments in my lab to play around with. As you may see in the below screenshot lease expires in about a months time



Pre-Requisites before making any changes to Database


Let's now connect to vRA's Postgres database. You may use a shell session to connect or use the pgAdmin tool. Anything works.


Use below query to find out how many deployments we have to modify whose expiration date is in future

select name,status,leasestate,resourcetype_id,lease_end_date from cat_resource where 1=1

  and status = 'ACTIVE'

  and leasestate in ('ACTIVE','ACTIVE_REMINDER_SENT')

  and resourcetype_id = 'composition.resource.type.deployment'

  and lease_end_date is not null

  and lease_end_date > now();



Note: In my lab, since expiration is less than 24 hours, leasestate is set to ACTIVE_REMINDER_SENT , normally if the expiration is more than 24 hours it would be set to ACTIVE


Step#1

Begin a transaction



Step#2

Modify deployment records


Step#3

You're modifying any dependent children or any of sub dependent records



Step#4

Updating software components if it exists


Step#5

Changing cat_resource table with a null value under lease_end_date to change expiration to "NEVER EXPIRES"




If you're satisfied with the output and it matches the number of deployments then

commit; 

otherwise

rollback;





Step#6

If committed, then you would find the lease status of the VM's changed to "NEVER EXPIRES"




Click here to get the whole query


Happy Learning. As stated above before making any changes to database ensure appropriate backups are taken.



0 views

Subscribe Now

  • Twitter
  • Facebook Social Icon

Copyright © 2019 nukescloud