Custom Property data deduplication

[Jeremy_VE]

Is it possible to set the value of a custom property to be the value of another custom property?

I have a vCO workflow that I have made its input variables custom properties on a vCAC blueprint.  One of the properties specifies the virtual machine name (ExternalWFStubs.MachineProvisioned.vmName).  Now I'm setting the name of the VM via the vRO blueprint (VirtualMachine.Admin.Name) since I'm deploying the virtual machine using a vCAC blueprint rather than having vCO do it.  This is because I'm using network profiles for dynamic network creation and I find it easier to let vCAC handle this rather than write the workflows to have vCO handle everything.

Is it possible within vCAC to link the value of VirtualMachine.Admin.Name to the value of the WFStub vmName property or vice versa?  I'd really hate for users to have to put in the same data multiple times.

Since vCAC is calling vCO to create the virtual machines anyways, I can only imagine that the data is accessible from there as well.  I'm still learning vCO so if it's easier to do it there, please let me know.

Jeremy

[sbeaver]

Hey Jeremy,

Inside vCAC when setting up custom properties you can tie them to other properties and or multiple properties.  When you setup the value for that custom property and you want to reference a different property you need to but the value in {}    Let me give you one example I use for the hostname

I have a couple of different properties that are automatically populated based on lbusiness unit location, os type, and function. To create my hostname prefix I combine the different properties into the hostname and it looks like this vcac

custom.hostname.prefix = {bu}{os}{loc}{func}

Is that what you are looking for?

Steve

[Jeremy_VE]

So if I want to make ExternalWFStubs.MachineProvisioned.vmName = VirtualMachine.Admin.Name I have to make ExternalWFStubs.MachineProvisioned.vmName={VirtualMachine.Admin.Name}?

I want the requester of the blueprint to specify the VM name and that value be what ExternalWFStubs.MachineProvisioned.vmName is set to as well.

Jeremy

[sbeaver]

It works that way for me and yes it should work for you but what is different in my environment is I manually created my workflow stubs with the designer.  I have not played to much with the method you are working the stubs yet.  That is on my list for my lab work to do starting next week.  If you want to test and make sure create a blueprint that will reference other properties.  Deploy a VM and then check the properties after the fact and make sure it looks the way you expect.

[stvkpln]

Here's a question... what are you trying to do, and why does this property need to translate to another one? If you're calling a stub vCO workflow, why not just use the original property in the workflow?

[Jeremy_VE]

How do I call the custom property on the vCAC blueprint from the vCO workflow?  To get the vCO workflow parameters as custom properties I had to basically export them using a vCAC workflow.  Is there a similar process to do the same for vCAC to vCO?  In truth, I'll just be mapping the vCAC custom property value to the workflow parameter within vCO as there are a bunch of workflows that use the already established vCO parameter and I don't want to go through all of them to change them if I don't have to.

I'm using vCAC to deploy the VM from a blueprint and using vCO to run a Powershell script in the guest OS.  vCAC allows me to deploy VMs easily onto dynamically provisioned, NSX backed networks without having to create a bunch of vCO workflows to accomplish the task.  Because vCAC is deploying the VM, I have to use the VirtualMachine.Admin.Name property to name the VM something besides the default machine prefix/# scheme for the business group.  The parameter custom property coming from the vCO workflow needs to be linked to this vCAC custom property in order for the use not to have to input the name of the machine twice.  If I was doing everything from within vCO this would be no problem.

Am I wrong and there's an easier way?  Please remember, I'm a vSphere infrastructure and VDI guy just getting started in cloud/orchestration.

On that note, I've read that the modification of workflows and workflow stubs can be done through the VCAC designer. However I've also read that the VCAC designer is on its way out the door and that it's use should be limited.  Is this true or is the designer still a valuable tool with adequate life left in the product?

Also if anyone can point me in the right direction for some good materials on vCAC and vCO, I'd much appreciate it.

Jeremy

[sbeaver]

As far as the designer goes, in my opinion it is in a transition state as VMware is looking to expand on the extensability.  In case you are curious, let me share what I am doing for hostnames

http://dailyhypervisor.com/vcloud-automation-center-vcac-5-2-custom-hostnaming-extension/    

I started with his workflow and "customized" it to add in other tasks such as putting together the hostname and then query the IP system for the net available number for the name as well as getting the next IP and registering it all with the DNS system and so forth.  I highly recommend checking out a lot of the different articles on the dailyhypervisor sites.  They also have another workflow that I use for AD management and pre-creating the computer account in the correct OU, which I piece together the proper location with logic in an early script.

[Jeremy_VE]

I asked about designers lifespan because I've read articles about using a designer to import vCO workflows into the vCAC virtual machine deployment process via stubs.  I'm accomplishing this by exporting vCO  workflow parameters to the blueprint by way of a vCAC extensibility workflow inside of vCO.

[Jeremy_VE]

So I got this extension working on component blueprint.  I'm trying to get this working with a multi-machine blueprint (vRealize Automation vCAC 6.1 Ultimate Multi-Machine Blueprint Extension v1.0 — DailyHypervisor), but the {APP} portion keeps coming up as "undefined".  Any ideas?

[sbeaver]

When and where in the process does the {APP} property get defined? Is it in the blueprint or a build profile or something else?

[Jeremy_VE]

It's in a build profile that is attached to the multi-machine blueprint.

On the component machine blueprint I have the a build profile attached that has the following custom properties configured in it:

Name= Custom.Common.ComponentMachine.HostnameString     Value= {LOC}{GRP}{APP}{##}

Name= Custom.Common.SetCustomHostname.Execute              Value= true

On my compute resource I have a custom property that defines LOC, and on my business group I have a custom property that defines GRP.

On the multi-machine blueprint I have a build profile attached that has the following custom properties configured in it:

Name= DCHOST.APP          Value= DC          DCHOST is the name of the component that I have added to the MM BP on the Build Info tab.

On the multi-machine blueprint I have a custom property:

Name= UltimateMultiMachine.Execute          Value= true

Looking at the vCAC Recent Tasks, 2 workflows are kicking off. 

1. "Set Ultimate MM Properties" started

2. "Set Ultimate MM Properties" started (again)

3. "Set Custom Hostname" started

4. "Set Ultimate MM Properties" completed

5. "Set Ultimate MM Properties" completed

6. "Set Custom Hostname" completed

7. "Set Ultimate MM Properties" started (this one actually sets the value of {APP}

8. "Set Ultimate MM Properties" completed

So basically the Custom Hostname workflow which actually sets the VM name finishes prior to the APP property being applied.

I'm going to try removing the Execute property from the Component Blueprint to see what happens.

[Jeremy_VE]

Removing the Execute property from the Component Blueprint build profile completely broke it.