The last few deployment tests that I have run in Cloud Assembly have resulted in deployment failures, not because there is anything wrong with the blueprint in question but because the extensibility has failed. Normally I would put this down to mistakes in coding or bad error handling but in this case my workflow is fine. Something else is going on…

Looking at the request details of a failed deployment you can see the problem. The extensibility workflow that is configured within my subscription cannot be found on the vRO server. However, that vRO server is not the one it should be using…

Lets look and see what’s going on. There are a number of vRO instances added into my cloud organisation. Only one of them is mine, the rest belong to other members of my team.

My extensibility workflows only exist on my vRO server so it stands to reason if Cloud Assembly tries to find and execute them on another vRO instance then the execution will fail. To fix this I need to restrict Cloud Assembly to just use my vRO instance.

Capability Tags within Cloud Assembly are used to put constraints on provisioning so that you can target specific endpoints etc. I should be able to use this methodology to restrict the vRO instance selection.

Here I have added a capability tag to my vRO instance. This is only one part of the configuration though as I need to pair this somewhere else in Cloud Assembly. Normally you would add constraints into the blueprint but in this case the capability tag needs to go elsewhere.

My project has a section for applying extensibility constraints so this is where my capability tag needs to be added. I have made it a hard constraint for my environment.

Now my deployments work consistently using the same vRO instance.