VMware Cloud Community
IntegraRoger
Enthusiast
Enthusiast

Question: vRA 7.2 Deployment Unique Identifier

Is there a system variable (or REST URI) that contains a unique identifier for the current request? The request would be either a single or multi system deployment with software installation.

Thanks in advance,

Roger

0 Kudos
6 Replies
jasnyder
Hot Shot
Hot Shot

What information are you trying to receive and where do you want to receive it?  Here is an example of properties sent during a deployment provisioning request to a vRO workflow via event broker system, which was call on the POST MachineProvisioned state:

lifecycleState = HashMap:1517510686

componentId = Machine_Resources

blueprintName = CentOS 7

componentTypeId = Infrastructure.CatalogItem.Machine.Virtual.vSphere

IaaSTimeoutId = 9395

endpointId = eedfbd49-d63f-4e67-a519-3813e27fe206

machine = HashMap:800921255

requestId = 2191268a-dbcc-4ce7-b922-e3b578f8201b

The request unique identifier is in the requestId variable.  This is only information about the request, not the resources provisioned from the request.  Within the machine property are the following properties, which are essentially the custom properties set before and during the request.  These are not always the same set of properties, depending on how the blueprint, business group, and reservation are configured, but it might give you some ideas of what can be pulled in this way.

0. VirtualMachine.Cafe.Blueprint.Id = CentOS7

1. __Clone_SnapshotId = 2

2. VirtualMachine.Disk0.Name = Hard disk 1

3. __InterfaceType = vSphere

4. VirtualMachine.Network0.PrimaryDns = 10.10.1.1

5. VirtualMachine.Network0.DnsSuffix = lab.local

6. __VirtualMachine.Allocation.InitialMachineState = SubmittingRequest

7. VirtualMachine.Cafe.Blueprint.Component.TypeId = Infrastructure.CatalogItem.Machine.Virtual.vSphere

8. VirtualMachine.Admin.UUID = 501edba1-69ea-c3f5-b35d-6ae20a324faf

9. __Clone_VMSnapshotId = 53

10. __api.request.id = 2191268a-dbcc-4ce7-b922-e3b578f8201b

11. VirtualMachine.Disk0.Size = 20

12. __api.request.callback.service.id = 4325674e-3e20-4cee-91eb-3b8fd44a2534

13. __DailyCost = {"type":"moneyTimeRate","cost":{"type":"money","currencyCode":"USD","amount":1.8649999986689816},"basis":{"type":"timeSpan","unit":4,"amount":1}}

14. Hostname = test7

15. VirtualMachine.Cafe.Blueprint.Name = CentOS 7

16. Cafe.Shim.VirtualMachine.TotalStorageSize = 20

17. __Legacy.Workflow.ImpersonatingUser =

18. __Legacy.Workflow.User = jsnyder@lab.local

19. __VirtualMachine.ProvisioningWorkflowName = CloneWorkflow

20. VirtualMachine.Network0.DnsSearchSuffixes = lab.local

21. VirtualMachine.Network0.SubnetMask = 255.255.255.0

22. Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned = *

23. VirtualMachine.Disk0.ExternalID = 6000C295-0227-c004-a9d1-09a805bc5159

24. __request_reason =

25. __Cafe.Root.Request.Id = db5886f8-700a-403a-aa62-c9ee6f8ef2b0

26. callExternalWorkflowActivityPostBuildingMachine = False

27. _number_of_instances = 1

28. VirtualMachine.Admin.AgentID = 716e1e42-6918-c128-a06c-a77fa267cb5d

29. VirtualMachine.Disk0.IsClone = true

30. VirtualMachine.Network0.MacAddress = 00:50:56:9e:d7:32

31. __clonefromid = 1feed020-e5b2-4cff-911e-3bc2a0f6ec56

32. VirtualMachine.Disk0.DeviceID = SCSI (0:0)

33. __Cafe.Request.BlueprintType = 1

34. VirtualMachine.Memory.Size = 1024

35. VirtualMachine.Cafe.Blueprint.Component.Cluster.Index = 0

36. VirtualMachine.CPU.Count = 1

37. __Clone_Type = Linked

38. __clonespec = EL-VRA7

39. VirtualMachine.Admin.TotalDiskUsage = 20480

40. VirtualMachine.Disk0.Label = Hard disk 1

41. trace_id = mzk4r1cM

42. __trace_id = mzk4r1cM

43. __iaas_request_binding_id = e880c591-aef9-48bf-8e3a-ac1cd8bb71d4

44. VirtualMachine.Cafe.Blueprint.Component.Id = Machine_Resources

45. VirtualMachine.Network0.Address = 10.10.1.195

46. VirtualMachine.Disk0.Storage = NFS-01

47. Vrm.ProxyAgent.Uri = https://vra72iaas01.lab.local/VMPS2Proxy

48. VirtualMachine.Storage.Name = NFS-01

49. __clonefrom = vra72_CentOS7_LinkedClone_Base

50. VirtualMachine.Network0.Gateway = 10.10.1.254

51. VirtualMachine.Network0.Name = VMPublic

52. DisplayNameSuffix = test.local

53. VirtualMachine.Disk0.IsFixed = True

If you're looking for the deployment name, you would have to use the requestId to get back to the resources that were provisioned for that request and find the top level resource and it's name/ID.  You can set the name using the _deploymentName custom property.  From the Custom property reference:

When added to a blueprint, this property allows you to specify a custom name for the deployment by setting the value of _deploymentName to your custom string. If more than one instance of this deployment is provisioned in a single request, your custom name becomes a prefix. If you want users to specify their own deployment names, set this custom property to allow override. The following two caveats are required for usage: 1) You must add this property at the blueprint level, not at the component level. For example, when creating or editing a blueprint, click the Properties tab and then select Custom Properties > New to add the _deploymentName property to the blueprint. Do not add the property to a machine or other component in the blueprint. 2) You must add this property as a separate property and not as a member of a property group.

Does that address the question?  If not, can you provide a little more elaboration on what you're looking for?

IntegraRoger
Enthusiast
Enthusiast

The RequestID would be the bomb...in this case, if I can avoid Orchestrator, that would make things easier...

What I am trying to do is run a script during provisioning that sets the values in a CSV file based on the roles for a Sharepoint farm. The first system to run (or the only system in an all in one deployment) would check for the existence of the file on our Definitive Media Library (DML)temp space, and if it is not there, create it based on properties set in the deployment properties. If this is a multi machine farm, the secondary (tertiary etc) systems would add a line to the CSV file. Once built, the CSV file will become consumed in later steps to configure the farm irregardless of whether this is a single system or multi system deploy.

What I need is a unique (to the deployment) identifier with which to create a temporary directory that would be destroyed 2 days later (we have this mechanism setup on our DML). I'm thinking to use _resources~BlueprintName~EXTERNAL_REFERENCE_ID as a unique identifier but I cannot find anything that details what this is....

0 Kudos
IntegraRoger
Enthusiast
Enthusiast

jasnyder​ you mention the RequestID, and that would seem to be my best bet... I'm fighting with either the ability to get reliable information from vRA itself using the bind resources (_resource~SystemName~someResourceHere) or to make a rest call in Powershell (somehow every curl call I make gets routed to Invoke-RestMethod.

For the Rest call to get a token I have to use:

$token= Invoke-RestMethod -uri https://${AppDServer}/identity/api/tokens -ContentType "application/json" -Method Post -Body $json where $json contains:

$identityRequest = @{

    username=$($AppdAdmin+"@"+$DBDomainName)

    password=$AppdPSWD

    tenant='TenantName'

}

$json = $identityRequest | ConvertTo-Json

which works fine, but I can't seem to find any reasonable examples of using Invoke-RestMethod to make a call to get the RequestID. I've been able to get INTO the REST API, but Winblows is such a dear to work with... With:

Invoke-RestMethod -uri "https://${AppDServer}/catalog-service/api/consumer/resources/?page=2&limit=1" -ContentType "application/json" -H @{"Authorization"="Bearer $($token.id)"}

I can at least get a response, but any chance you could tell me what the URI is for the requestID? I understand that its is somewhere in https://${AppDServer}/catalog-service/api/consumer/resources/ but I've not had any luck either getting a REST extension working, or getting Windows to give me any meaningful output.

The only other methodology I can think of is exporting information from Orchestrator... getting the requestID is easy enough IN Orchestrator, but how does one export that data to a powershell script in the workflows of building an application server?

Thanks in advance...

Roger

0 Kudos
jasnyder
Hot Shot
Hot Shot

What about this idea - create a property definition for "UniqueID" and bind it as a drop-down of type string to external values returned by a vRO action.

The action content looks like this (no params, returns Array/string):

//taken from: https://stackoverflow.com/questions/1349404/generate-random-string-characters-in-javascript

var text = "";

var possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

for (var i = 0; i < 24; i++)

  text += possible.charAt(Math.floor(Math.random() * possible.length));

return [ text ];

Its job is to generate a 24 character random string to act as a unique id for the deployment.  You set the property on the blueprint and bind the software component property to that.  The drop-down will be required and only have one value which should be unique to the deployment, but the property would get passed down to all the nodes being provisioned within the same deployment.

0 Kudos
IntegraRoger
Enthusiast
Enthusiast

I can create an action in my own folder, but how do I get vRA to recognize the folder? using the extensibility mechanism, I can get the requestID, but I can't seem to get my vRA installation to see my action folder... I'm guessing I need to re-inventory it? (although this happens daily and I don't see the other actions in there...)

0 Kudos
jasnyder
Hot Shot
Hot Shot

I spent a fair amount of time working on a solution to this.

As far as my last idea - this won't work because when you bind the action result to the property definition, it will try to verify that the selected value is in the list of available values which can never be the case because it returns a different value every time.  So setting the parameter on the blueprint and flowing it down to the machine and binding it to the software component won't work this way, unless you want the user to enter a unique string by hand.  That does work.

I tried the approach of using a vRO workflow called by EBS subscription to get the requestId and write it back to a property on the machine which is bound to the software component property.  It appears that the software component property takes the original input at the request time and does not respect any property updates made as a result of the EBS (subscribed a blocking workflow to the PRE Requested provisioning state and had it update a property on the machine which had been bound to the software component property; the machine property gets updated with the requestId but the software component just receives whatever the input value was at the time of the request)

So the next approach was to kind of hack both of those approaches together.  I made a stub XaaS workflow and made it part of the blueprint.  The XaaS workflow doesn't have any inputs or outputs and does nothing.  But I added a text field on the blueprint form called "UniqueString" and made it a drop-down which pulls values from the vRO action that generates a random string (same code I gave you before).  Now when you request the blueprint, you have to switch to the XaaS form, drop the field down, select the single unique value and submit the request.  In the software component I bound the input property to the value of the XaaS blueprint's UniqueString field.  This value is set at request time, and so this works as expected.

But it's annoying because the user has to make extra steps to request the value in the non-intuitive XaaS blueprint form.  I tried to make it a text box constrained to the return of the vRO action, but vRA doesn't like that and won't allow the blueprint to be saved in that state.

So there are perhaps 3 other approaches to this if you don't like that one.  You could make an XaaS blueprint that submits a vRA request for the main blueprint but sets the unique identified property to the request ID as part of the submission process.  In this case the request ID would be that of the XaaS blueprint request but not the subsequent request.  You could also have the XaaS blueprint generate the random string and submit that with the request.  You would have to expose whatever parameters you want the user to enter as part of the outer XaaS blueprint form.

In other words, the user would request XaaS --> vRO workflow --> vRA catalog request for sharepoint item with properties set by vRO workflow.

The other approach is to use the software component to pre-position the install script in a temp directory and then kick the script off using a vRO workflow that runs after the machine is finished provisioning (using event broker).  Then you would have access to the requestId property passed in the payload to vRO.  You would either have to hardcode the user credentials in the workflow to call the program in guest that runs the script or you could cache them in a configuration element attribute and link the values that way.  You would also need to grab the externalReferenceId to map the machines back to the vCenter VM in order to call the Run program in guest workflow.  So there is a little bit of extra work there.

One final way is to create the property definition but set a regex to define what can be entered:

^[a-zA-Z0-9]{24,30}$

This will require the user to enter a unique alphanumeric string with no spaces or special chars between 24-30 characters in length.  The idea being they mash the keyboard to generate a unique string.  You bind the software component to that property on the machine which inherits from the blueprint.

None of these are really very awesome...

0 Kudos