Highlighted
Expert
Expert

vRO Updated properties to Software Component

Jump to solution

I need to have a VM property updated by vRO and then use it in a Software Component to install an application.  When I bind the Software Component property to the VM property, the information seems to be copied at request time as the software component is still working with the pre-vRO updated value.  Is there some flag, or something, that I need to set to tell vRA to use the dynamically updated value and not the value when the user clicks Submit?

vRA 7.3

Carl L.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Immortal
Immortal

Ok, so this is a Windows Failover Cluster. I get how you're doing this with PowerShell, I'm just wondering how you're deriving the values that get set as properties $clusterIP and $clusterName (meaning, by what logic, process, or methodology you're using to compute/formulate them). You said at the outset that these were custom properties that were altered within vRO, so I'm guessing they're defined on the blueprint or machine component, then altered through vRO scripting somehow. Like I said, I'm not sure that when using bindings to these custom properties that it will "replace" that value with whatever vRO shoves back into vRA. But here's a workaround I developed for a somewhat similar use case. I actually wrote a blog about it here (rough draft state). The blog outlines it pretty well, but the gist of it is that since the altered custom property does get passed into the payload, and that payload is written out to the application bootstrap agent's log file, you can use a method that extracts whatever value you wish, set that as a computed property, and then assign that computed property to be a variable in your script.

So in your case, you'd use the method and pipeline I created to set a computed property (set the computed flag in your software component). You then use your PS command as normal but reference the name of this computed property for the $clusterIP argument and same for $clusterName argument. You can also bind to this computed property across other components and in so doing pass its value around a deployment. Read that blog and see if it makes sense. I wrote this with Linux in mind, but the principle is the same with Windows (except probably with the cmdlet Select-String). If you're not able to come up with a Windows equivalent of that bash example, let me know and I'll ruminate over it.

View solution in original post

0 Kudos
10 Replies
Highlighted
Immortal
Immortal

I don't think I've tried that before. At what stage are you updating custom properties? And is this a system custom property or something custom? To my knowledge, there is no "switch" to control how binding is done other than the custom property name.

0 Kudos
Highlighted
Expert
Expert

Requested.Pre (the very first event).

What I am trying to do is:

1) User requests an MS Cluster

2) When Master VM is requested, call vRO to get Cluster Name and VIP and assign those to property in vRA Master VM.

3) Have MS Cluster Install Component, pass those values on the install script to install the cluster.

If you can think of an easier way, I am open to any suggestions on how to create, on the fly, the cluster name and VIP for the install.  I even looked at having a XaaS blueprint that returned a Custom Resource IP (then I know it would get released on destroy) but don't see any objects in vRO that I could use for the custom resource.

Thanks,
Carl L.

0 Kudos
Highlighted
Immortal
Immortal

Carl, when you say "MS Cluster" what does this mean? How are you determining cluster name and VIP? I know you said vRO, but can you explain more details? There are a couple possibilities here I can see...

0 Kudos
Highlighted
Expert
Expert

Thanks so much for your help!

MS Cluster (aka Windows Cluster) . Specifically, the powershell command "New-Cluster -name $clusterName -node $h,$secondaryNode -staticAddress $clusterIP -noStorage -force" where $h is the local host and the rest comes from vRA Application Services.  Right now, I am hard coding the Cluster name and VIP that vRO returns.  The next stage is how to generate them. 

Thanks,

Carl L.

0 Kudos
Highlighted
Immortal
Immortal

Ok, so this is a Windows Failover Cluster. I get how you're doing this with PowerShell, I'm just wondering how you're deriving the values that get set as properties $clusterIP and $clusterName (meaning, by what logic, process, or methodology you're using to compute/formulate them). You said at the outset that these were custom properties that were altered within vRO, so I'm guessing they're defined on the blueprint or machine component, then altered through vRO scripting somehow. Like I said, I'm not sure that when using bindings to these custom properties that it will "replace" that value with whatever vRO shoves back into vRA. But here's a workaround I developed for a somewhat similar use case. I actually wrote a blog about it here (rough draft state). The blog outlines it pretty well, but the gist of it is that since the altered custom property does get passed into the payload, and that payload is written out to the application bootstrap agent's log file, you can use a method that extracts whatever value you wish, set that as a computed property, and then assign that computed property to be a variable in your script.

So in your case, you'd use the method and pipeline I created to set a computed property (set the computed flag in your software component). You then use your PS command as normal but reference the name of this computed property for the $clusterIP argument and same for $clusterName argument. You can also bind to this computed property across other components and in so doing pass its value around a deployment. Read that blog and see if it makes sense. I wrote this with Linux in mind, but the principle is the same with Windows (except probably with the cmdlet Select-String). If you're not able to come up with a Windows equivalent of that bash example, let me know and I'll ruminate over it.

View solution in original post

0 Kudos
Highlighted
Immortal
Immortal

Bah, I went ahead and just banged this out this morning since I was curious myself how to do it. Here's what I'd do.

Create a property which is computed (if you need to bind to it from another machine element; if not, no need).

Use this code to extract the custom property that is delivered to the provisioned machine and present in the payload:

$string = Select-String -Path C:\opt\vmware-appdirector\agent\logs\darwin-agent*.log -Pattern "virtualmachine.network0.address" | Select-Object -Last 1

$string -match "(?<=virtualmachine.network0.address' value ')[^']*" | Out-Null

$myvar = $Matches[0]

Write-Output "My IP is $myvar"

Replace the custom property name you want in both places you see there. Alternatively, you could create this as a property and pass it in as a variable so you don't even need to hard-code that in your script.

The Write-Output statement there is just to prove (without having to go to the machine) that it's working properly.

EDIT: Software component example uploaded here => Any Custom Property Extraction Windows - Samples - VMware {code}

0 Kudos
Highlighted
Expert
Expert

Oh wow, that is gross but it works 🙂

FYI, The Windows version is at C:\VRMGuestAgent\GuestAgent.log

Thanks so much!  On to phase 2, generating the cluster name and getting the IP from an IPAM system.

Carl L.

0 Kudos
Highlighted
Immortal
Immortal

It's definitely hacky, but it works fine and isn't too complex. I update the previous post with a link to the software component I built that has all the logic provided, so you might want to give that a shot. You could either copy-and-paste the PowerShell into an existing component, or use this component as a "base" and binding across to a different software component. The latter is probably what I'd do to make it modular and reusable.

0 Kudos
Highlighted
Contributor
Contributor

Not sure if it was available in the older agent but now there is a custom.properties file that is easier to parse. Here is a powershell function that will put the properties into a hash

function Get-VraProperties

{

    $properties = @{}

    Get-Content "C:\opt\vmware-appdirector\agent\custom.properties" | ForEach-Object {

        $s = $_ -split "=", 2

        $properties.Add($s[0], $s[1])

    }

    return $properties

}

Highlighted
Enthusiast
Enthusiast

I have a similar need: get the mac address and add some UDEV rules on RHEL7.

on VRA 7.6 did it using the custom.properties file as suggested by @vbranden.

Before finding this blog, I had tried the same approach as the original poster: using EBS and updating custom properties bound to the software component.

Not working: the SC properties keep the value they had at the time of the request. I'm at a loss why. Perhaps the binding is just a copy of the value at request time?

Would it be possible to update directly the SC properties form the EBS workflow, instead of the custom properties off the blueprint?

0 Kudos