If you get a 404 error in vRA when you click on the F5 object in the canvas, follow these steps to fix it. This seems to be a bug with vRA that happens when multiple external vROs are sharing the same vRA.
The Problem
Dragging or viewing an F5 Component into the vRA blueprint canvas results in an error
Theory
If multiple vRA tenant exists for a vRA, the last vRA tenant to run the SovLabs Configuration workflow (for a new install or an upgrade) will have a working F5 XaaS. All of the other vRA tenants will now error.
Temporary Workaround
Get F5 XaaS component working for your tenant (most likely, it will error on all the other tenants for that vRA instance)
- Login to vRO client for the tenant that errored
- Click on Workflows tab
- Drill down folders SovLabs > Configuration > Subflows
- Run vRO workflow Process Modules Updates
- Select the appropriate CAFE host
- Type in “F5” as the module
- Type in the tenant name
- Select Yes for “updateF5DefaultRestipe”
- Click Submit
- Workflow should be successful
Additional Thoughts
The purple/blue highlight “Update F5 Virtual XaaS” is the script task where I update a tenant’s F5 XaaS blueprint “F5 Virtual – SovLabs Modules” (which is the F5 component that you drag in)
An update was necessary because of the new fields we added for F5 (persistence profiles, profiles, member node settings, split out into 3 tabs)
In the scriptable, it calls:
var result = client.putWithVariables("tenants/{tenantId}/blueprints/{blueprintId}", bpObj, [cafeHost.tenant, blueprintId]); bpObj = JSON structure of new/latest F5 XaaS blueprint client = cafeHost.createRestClient(vCACCAFEServicesEnum.ADVANCED_DESIGNER_SERVICE);
Unsure why it causes the other tenants to lose its F5 form when the latest tenant runs SovLabs Configuration (which calls Process Module Updates), but it does… Perhaps to do with database?
Related articles
0 Comments