Impossible to change lease of VM with vRO

[tchristin]

Hi,

I'm trying to create a  new resource action in replacement of 'change lease'.

My goal is to add some control of maximum lease duration and maximum number of renewals.

The problem is not to implement control but to change the lease.

All workflows found about this subject don't work on vRA 7 (7.0.1 at this moment with embedded vRO)...

The most recent Constrained Change Lease - Freebee, written by SeanKohler‌ generate this exception on the request :

Internal error processing completion of blueprint [CHANGE_LEASE] request [5616bb15-0200-4fd9-9e1c-7062334d5b9b]. Status so far: [SUCCEEDED]

It seems to be a date format problem but all my test failed with different formats...

Since I still have not got an answer on my reply on this thread, I hope having more chance by creating my own there.

Thanks for your help.

Tim.

[SeanKohler]

I haven't tried it in 7 yet, but will be in the next week or so.  If I come up with something that works, I will let you know.

[SeanKohler]

My original reason for doing this was to constrain lease extension to a reasonable time.  (e.g. a blueprint resource which can live for 30 days should be able to be extended--but within some limit)  In 7.x, it appears this has been solved by allowing a Deployment Lease constraint (max) to be the furthest a deployment can be extended.  So a deployment that has a 30-day max lease can be extended from today to 30 days (but not to 60 or 90 or infinite).  This is a good behavior in my book.

Do you have different reasons for wanting to run Lease Requests from VRO?

With the improvements to CloudClient, I would more likely look toward sending in a formatted request through a CloudClient command.  (VRO Workflow to SSH to Linux Host to run CloudClient request)  This would be based on resource actions allowed to the cloud client user and would require resource lookup and action request.

[tchristin]

Hi Sean,

Thanks a lot for your reply.

In 7.x, it appears this has been solved by allowing a Deployment Lease constraint (max) to be the furthest a deployment can be extended.  So a deployment that has a 30-day max lease can be extended from today to 30 days (but not to 60 or 90 or infinite).  This is a good behavior in my book.

I'm not able to see this behavior : all accounts can extend lease about years, although the max lease set is 180 days...

What I want is to allow only one lease renewal (I will use a custom property on te vm that will be incremented at the renewal) and that renewal would not exceed the initial maximum lease (as you mentioned in your message).

I think to permit lease change with vRO we need to change it on deployment and virtual machine but I'm not able to face the deployment part in vRO.

Thanks again !!

Tim.

[SeanKohler]

For certain, that is the behavior in 7.2 (just not sure when it switched).  Once you set maximum lease, if you try to extend lease longer than the window of the maximum lease... it tells you that you cannot.

Can you get out of 7.0 and into 7.2?

[SeanKohler · Accepted solution]

So it can be done from VRO using a valid REST JSON POST against %resthost%/catalog-service/api/consumer/requests.

To do this, you have to get the machine CatalogResource first and look up the ID, Machine Name and know the ID for the resourceAction (which I would look up off the resource for consistency across tenants).  You would also get date string as a variable. These and tenant & subtenant reference values would be variable in the JSON.

{
  "@type": "ResourceActionRequest",
  "resourceRef": {
  "id": "e6a418ba-6c04-47c9-8d8a-34ad30c032c7"
  },
  "resourceActionRef": {
  "id": "b6082a9b-bb7d-433b-bb0e-bd0470ee85df"
  },
  "organization": {
  "tenantRef": "vsphere.local",
  "tenantLabel": "vsphere.local",
  "subtenantRef": "cf666f51-203d-4ce8-a920-499ea32f7e8a",
  "subtenantLabel": "NOTPUBLIC"
  },
  "state": "SUBMITTED",
  "requestNumber": 0,
  "requestData": {
  "entries": [{
  "key": "provider-MachineName",
  "value": {
  "type": "string",
  "value": "NOTPUBLICMACHINENAME"
  }
  },
  {
  "key": "provider-operationId",
  "value": {
  "type": "string",
  "value": "Infrastructure.Machine.Action.ChangeLease"
  }
  },
  {
  "key": "provider-machineId",
  "value": {
  "type": "string",
  "value": "1ecbb3be-4f7d-46ef-94c3-3453e5f7024c"
  }
  },
  {
  "key": "provider-ExpirationDate",
  "value": {
  "type": "dateTime",
  "value": "2017-01-25T10:15:00.000-0700"
  }
  }]
  }
}

You can access the swagger documentation for the REST services by going to...

%yourVcacServerUrl%/component-registry/services/docs

In this case, I am using a REST helper package I wrote... but any method would do.  (Go to Grant's site... he often has valuable information for offer:  Postman Collection for the vRA7 API - grantorchard.com)

It can also be done with CloudClient which can be installed on a Linux script host and added as an SSH endpoint within the VRO plugin.  This way you can send a regularly formatted command-line command into the request process.  (CloudClient can be set up with logon sessions)

[tchristin]

Thank you so much Sean !

It works like a charm.

I'm just facing troubles about showing some input information (attributes) to the approver through a manual user action.

Thanks again !

Tim.

[SeanKohler]

My pleasure, Tim. 

Onward into the technological future! :smileycool:

>>I'm just facing troubles about showing some input information (attributes) to the approver through a manual user action.<<

They need to put more development into Manual User Action, Approvals, and Request Result FORMS in general.  I would like to be able to call vRO actions for any/all field inputs.  (like added into IaaS forms in 7.x)

If you post your question on manual user actions, I might be able to help.  We have some that provide values back to our "approvers" that show Reservation values selected during a custom reservation change request.

[tchristin]

Hi Sean,

Thanks for your reply.

I finally found the solution, thanks to VMwarebits : vRealize Automation 7 External Approval Policy with vRealize Orchestrator Workflow | VMwarebits.com.

To help other users, some details : I had to add the attributes inside the description of a display group (presentation tab in user interaction item of vRO) like this :

Requested by: ${requestedBy}
Machine : ${itemName}

Number of days to add to current lease : ${leaseExtension}
Requested expiration date: ${previewNewLease}

Reason: ${reason}

Additional description: ${description}

After that, the information are visible inside the manual user action into vRA or inside the workflow item "Answer...'.

I definitely agree with you Sean about manual user action & approval forms.

I'm facing a new issue on this point : Only vsphere.local users receive manual user action task into their inbox

If you have some time to help me...

Have a nice day,

Tim.