Accepted Solutions
Ok... so a bunch here.
Great you are using Cloud Client for one, but here is more information to help you in your thoughts and processes.
1. If you don't know how to already, be sure to know how to use Firebug or Chrome Tools(F12) to capture a request made in vRA. This gives you the postData for the makeRequest, which tells you exactly how the property keys are defined. (for the most part... there IS an exception with a couple of the ones that are "number" format... I think memory was one of them.)
2. Since you have Cloud Client, you can actually GET requests that were already made and see what the request was like... (you can get the Request ID from vRO inventory, from a cloud client listing, from the above makeRequest capture, and other ways)
CloudClient>vra request detail --id "a06a45da-cf76-4e67-9e23-b1e2dce11922"
Careful with the machineID there, it is not actually the right one for the provisioned "Resource"... for that we need the resourceRef.id (which can also be seen in the request). You will come to find that all the provider- part of the request are essentially the properties portion of the request, but many of them are provided by default. The only one you have to satisfy for this action call is provider-ExpirationDate.
3. With the resourceRef.id you can get the list of actions you can run with your account entitlements. And with the action ID and the Resource ID, you can get the fields it is expecting.
4. Now knowing the format (through several different ways), we can submit a proper set of properties in our request.
So at least... that is the idea behind all of it. Unfortunately for me... I am still using 3.3.1 (but will be moving to 3.4 soon) and there are bugs on the request callback for the Change Lease Action and default date values. It will probably work for you. I do change lease much differently as I wrapped an ASD request around it. I would use Cloud Client to call my ASD request. (which works as I take in all strings and do my type conversion in workflow.)
And that brings me to this...
>>> Can I pass multiple machine IDs via a single command? I would assume that I would comma-separate them and wrap the whole thing in quotes?
Nope. But you can have a vRO workflow that iteratively (and/or asynchronously) calls a Cloud Client Change Lease per machine. So you can have an array of machines, selected by the user or whatever (if you have ASD), and run the change lease on each machine in the array programmatically. That effectively allows you to do *one successful thing*, but do it many times from one request. (Edit: Or you could send a list of machines into a shell script and iteratively move through each, but I would steer you away from that type of methodology if I could... preferring to set orchestration iteration up in vRO.)
>>>3. Am I on the right track here?
Absolutely! You are on an awesome track and it should bring you great success. (with, of course, some struggles and frustrations... but that's life in technology I suppose)
Keep at it and share what you find!
Ok... so a bunch here.
Great you are using Cloud Client for one, but here is more information to help you in your thoughts and processes.
1. If you don't know how to already, be sure to know how to use Firebug or Chrome Tools(F12) to capture a request made in vRA. This gives you the postData for the makeRequest, which tells you exactly how the property keys are defined. (for the most part... there IS an exception with a couple of the ones that are "number" format... I think memory was one of them.)
2. Since you have Cloud Client, you can actually GET requests that were already made and see what the request was like... (you can get the Request ID from vRO inventory, from a cloud client listing, from the above makeRequest capture, and other ways)
CloudClient>vra request detail --id "a06a45da-cf76-4e67-9e23-b1e2dce11922"
Careful with the machineID there, it is not actually the right one for the provisioned "Resource"... for that we need the resourceRef.id (which can also be seen in the request). You will come to find that all the provider- part of the request are essentially the properties portion of the request, but many of them are provided by default. The only one you have to satisfy for this action call is provider-ExpirationDate.
3. With the resourceRef.id you can get the list of actions you can run with your account entitlements. And with the action ID and the Resource ID, you can get the fields it is expecting.
4. Now knowing the format (through several different ways), we can submit a proper set of properties in our request.
So at least... that is the idea behind all of it. Unfortunately for me... I am still using 3.3.1 (but will be moving to 3.4 soon) and there are bugs on the request callback for the Change Lease Action and default date values. It will probably work for you. I do change lease much differently as I wrapped an ASD request around it. I would use Cloud Client to call my ASD request. (which works as I take in all strings and do my type conversion in workflow.)
And that brings me to this...
>>> Can I pass multiple machine IDs via a single command? I would assume that I would comma-separate them and wrap the whole thing in quotes?
Nope. But you can have a vRO workflow that iteratively (and/or asynchronously) calls a Cloud Client Change Lease per machine. So you can have an array of machines, selected by the user or whatever (if you have ASD), and run the change lease on each machine in the array programmatically. That effectively allows you to do *one successful thing*, but do it many times from one request. (Edit: Or you could send a list of machines into a shell script and iteratively move through each, but I would steer you away from that type of methodology if I could... preferring to set orchestration iteration up in vRO.)
>>>3. Am I on the right track here?
Absolutely! You are on an awesome track and it should bring you great success. (with, of course, some struggles and frustrations... but that's life in technology I suppose)
Keep at it and share what you find!
Well it is definitely Friday... I think I edited that about 12 times due to mistakes. 