Potential Bug Found: HTTP 400 Errors for Dynamically Generated Dropdowns in Property Definitions when Multi-Tenancy is in Place - Workaround Included

[rmav01]

Hi all,

I've stumbled on an issue creating dynamically generated dropdowns for use in property definitions when the following conditions are in place:

1. You have a multi-tenant environment.

2. Each tenant is pointing to a DIFFERENT vRO instance. For example, you have a DEV tenant which points to your DEV vRO while your vsphere.local points to your Production VRO.

3. You are trying to configure a dynamically generated dropdown that is NOT on vsphere.local.

4. I'm using vRA version 7.1.

As I created the property definition and bound the values to the external vRO action that returns an array of strings, I received a generic "An error has occurred banner" on the GUI and the new dynamic property was not added. I was able to pick the vRO action from the list of items that are native to the configured vRO for my DEV tenant. It isn't until I clicked "Submit" that I received the warning banner. I was also unable to find the stack trace for this failure in the log section of the vRA GUI. In order to capture what is going on, I had to look at the catalina.out file in /storage/log/vmware/vcac. Here I saw the following at the top of an error stack trace shortly after clicking the "Submit" button:

com.vmware.vcac.platform.service.rest.resolver.ApplicationExceptionHandler.handleHttpStatusCodeException:673 - 404 not found

The workaround: I had to change the vRO configuration on the vsphere.local tenant to match the configuration on the DEV tenant. Before hand I tried to import the action from DEV's vRO instance into vsphere.local's, but I'm assuming the change in action GUIDs between the two still caused the same error to occur. Now I am able to get the dropdown working in the DEV tenant at the expense of having my vsphere.local pointing to something I do not want it to.

Maybe this is something that can be fixed in 7.2?

[MikeNox]

Thanks, this provided a "fix", but not permanant. Changing the default tenant from the built in local vro to using the external vro appliance built for the tenant with the issue solved it, but unfortunately this is not a viable solution since we have separate vro servers for each tenant.  I'm hoping that this gets fixed soon!

I also found these.  The first article seems to be an early iteration of the problem, and the second seem to show it will be fixed in 7.0.1 (but I am running 7.1 & it is dated after the release of 7.0.1).

https://communities.vmware.com/thread/534677?start=0&tstart=0

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=21405...

I don't think it was fixed (per second article).

Thanks again.

[GrantOrchardVMw]

Can either/both of you confirm that this is for properties that are set to either "All Tenants" or "This Tenant"?

[MikeNox]

In my issue, it was set to "This Tenant".

[MikeNox]

My environment consists of 1 vRA, 3 vRO, 3 Tenants (including default).

Original: Default went to builtin, others went to external.

Current: Default and tenant1 to external1 vro, Tenant 2 to external2 vro.

Originally external values for properties only worked on default.  Other 2 tenants received system exception/

After changing default tenant's vRO to external1 (same as tenant1), default & tenant1 worked with "This Tenant" & "All Tenants".  Tenant 2 (still on separate vro) failes with both "All Tenants" & "This Tenant".

It also seems that if the workflow exists on the the vRO server configured in default, it does not throw the error.

ie: I was able to create a property looking at com.vmware.vra.networks.getApplicableNetworks on tenant2 (looking at different vro than default).