Hi
This is one of the gotchas with vRA 7.x - The Catalog system deals in manageable resources where the IaaS system deals in single nodes (I actually think this is pretty logical since they are separate systems and it's useful to have that separation even if it makes things awkward. I *DO* think that the Catalog system should perhaps introduce the notion of a draft or pending resource for deployments in provisioning. They don't have to be manageable, just reported.... )
Anyway, we have had this problem before and have found a couple of ways to work with it
1. Used XaaS wrap the deployment request so we could do the following
i. Get the CatalogRequest JSON and detect each node instance to be provisioned
ii. Generate a new unique hostname for each node and apply it to the request definition (from a list or by scanning inventory)
iii. Create a CSV list of the peer node names and put it into a custom property on each node
iv. During IAAS phase for the master node, locate entities for each peer in the list (& wait for them to exist if needed - IaaS is all async!). You can manage the order using provisioning dependencies if you need to
v. Master node can now do all he needs to do
OR
2. There *should* be a property on each node for the following
__Cafe.Root.Request.Id
This used to be the ID of the Deployment request so all child nodes had this property (v7.2 I think but have not checked if it's still there in later versions). If you can cleanly identify the peers you are good to go.
Another alternative for this approach is to set a unique value for this property on the Deployment at request time
_deploymentName
This will have the same effect but you need to manage uniqueness of this value for each deployment.
-Eoin
