The property binding breaks dependencies (vRA 7.2)

[colummcgaley]

I've just recently started encountering this error. The long and short of it is I have a software component that needs to get the DNS Address of the Routed Network, and a couple of other addresses that are dynamically generated by a software component, and the designer is preventing me from saving the property.

I'm using a binding to pull the value from the On Demand Routed Network, but I'm getting "The property binding breaks dependencies." The binding I'm using in the below picture is Routed28Bit~dns~primary_dns. In theory, this should not cause any issue.

I've never encountered this issue before. It is not clear what is causing the issue here, as I have no explicit dependencies beyond the implicit ones generated by vRA. Any ideas?

Edit: The following binding works: _resource~SrvGroup~ip_address. This happens across multiple tenants.

[kwrobert]

I'm having the same exact problem in my vRA 7.5 deployment. Same error message trying to access the same exact property of an External Network blueprint component. I tried accessing the property through both (using your example for clarity) Routed28Bit~dns~primary_dns and _resource~Routed28Bit~dns~primary_dns, neither of which worked.

It's unclear what this means, what "dependencies" this is breaking, and why. Hopefully someone out there has an idea? My only lead is that, if you look at the deployment, the VM component is "Allocated" before the network component (see below). So maybe the "Allocate" step needs to occur before provisioning the network, and binding the Software Component Properties to properties of the network object creates an implicit dependency from VM -> Network that would prevent the "Allocate" step from running first. Far fetched, but possible and the only lead I have right now.

[daphnissov]

If you would share the blueprint or explain in detail its composition, I can have a look at it in my lab and try to understand what's happening.

[kwrobert]

Ok, do you want the YAML files that you get when exporting a blueprint using the Cloud Client?

[daphnissov]

Yes, if you can export the blueprint in question here with CC and attach, I'll take a look.

[kwrobert]

Here is the blueprint. Sorry for the delay! Got roped into some stuff yesterday. Let me know if the attachment has everything you need.

[daphnissov]

I had a look at your blueprint in my vRA 7.5 environment, and I don't have a problem binding to _resource~<network_profile_name>~dns. I did get an error about binding to <network_profile_name>~dns. That said, what doesn't make sense is *why* you're trying to do this in the first place. You have a software component which does nothing more than set IP information. This is commonly done through a Linux vCenter customization specification. So what's your usecase for trying to do it with a software component?

[kwrobert]

Agreed, generally I use custom specs to accomplish configuring guest networking. I was creating this mostly as a proof of concept, but would be useful if you weren't using the Clone action and CloneWorkflow provisioning workflow to deploy VMs. Also, if you weren't deploying to a vCenter endpoint, something like this might be necessary.

The problem occurs when you try to bind to nested properties of _resource~<network_profile_name>~dns. Does it still work for you if you try to bind to _resource~<network_profile_name>~dns~primary_dns​, for example?

[daphnissov]

I get what you're saying as to why you'd want to do it, but now you have more dependencies (and require the expensive vRA Enterprise license for software components) plus changing IP stack info on cloud-deployed machines, if different from what vRA has, may cause management trouble later.

In any case, no, you cannot bind to the specific DNS properties for whatever reason. But by binding to the parent "dns" property it should send them down as an array of strings. Barring that, an alternate suggestion I have is to use my own software component I wrote called "Any Custom Property Extraction" to strip out the custom property directly from the payload file. You can get it on {code} here with a link to an article explaining its usage. I haven't tested this with 7.5 but it should work. I actually have a slight modification I need to push up there with respect to the code, and maybe someday I'll have time to do it. It works the same way just reads a different file.