XaaS vm resource action marked as 'Built-in', icon non-editable in vRealize Automation 7.2

[smithgp]

While trying out vRealize Automation 7.2, I created an XaaS Resource Action against the 'IaaS VC VirtualMachine' (VC:VirtualMachine) resource type for an Orchestrator workflow. After publishing it, I found that I couldn't edit the icon for the action (in Administration > Catalog Management > Actions). And, it's marked as 'Built-in' in the scope column (which I think is the real problem) in that table. Additionally, if I go to a different tenant in vRA, I can see it in the other tenant's list of Actions, which seems wrong.

This same behavior occurs if I use the various workflows and actions in the vRA vRO plugin to programmatically create, publish, and edit the action in vRA from vRO.

This is different behavior than in 7.1, where the action gets marked as scope = 'Shared' and I can edit the icon and it doesn't show across tenant boundaries.

I couldn't find anyway to change the 'Built-in' state of the action in the vRA portal or api. It feels like a bug in 7.2.

Any help is appreciated. Thanks,

Greg

[kallischlauch]

Hey, have not come across this (yet). But for another problem (blueprints are always shared and cannot be made private to BG), I received a repsonse where someone changed it directly in DB. However it should also possible through Rest API.

maybe as last-resort options.

See what support has to say if different behaviour in 7.1

[DanieleUlrich]

Hi Greg

I had to analyze and solve a similar issue: I copied some XaaS Ressource Actions with a custom icon from one tenant to another by using the cloud client.

For API access or on the vRA portal I got for all three actions this error message:

"errors":[{"code":10112,"message":"Authorization error.","systemMessage":"Icon with ID 788bfdb3-02f8-48b1-a4ec-9d1752ce2b08_icon does not belong to your tenant.","moreInfoUrl":null}]

I tried to upload a new icon first but this failed with exceptions, then I found your post in this forum with the reply from kallischlauch‌ pointing to the database.

So I checked the HTML code with the dev tools:

I could find the 3 icon ids that were not working:

aefe005b-1c60-4b6b-ab1d-04b0034ef263_icon

788bfdb3-02f8-48b1-a4ec-9d1752ce2b08_icon

c1e71d98-ffa1-49f7-ae0c-6b79d40df154_icon

I checked the vRA database and found a table "cat_icon" that contained a row per icon with a tenant-id that was set to the tenant where I first added the icon. So I simply set this tenantId to NULL:

update cat_icon  set tenant_id = NULL where id = 'aefe005b-1c60-4b6b-ab1d-04b0034ef263_icon';
update cat_icon  set tenant_id = NULL where id = '788bfdb3-02f8-48b1-a4ec-9d1752ce2b08_icon';
update cat_icon  set tenant_id = NULL where id = 'c1e71d98-ffa1-49f7-ae0c-6b79d40df154_icon';

After that it worked again. To my mind this is a bug for all shared XaaS resource actions at least. By copying the action the tenant binding doesn't make sense anymore (if it was useful before).

I exported the XaaS resource action and checked the content of the yaml file of the resource action (41ea2a5e-1049-41b5-b212-c5629e28073b-xaas-resource-action) and found for example:

id:

  id: "41ea2a5e-1049-41b5-b212-c5629e28073b"

access: "external"

workflowId: "aefe005b-1c60-4b6b-ab1d-04b0034ef263"

name: "Add Database"

So the icon gets the name of the workflow id and this will never work out of the box when two tenants share the same workflow.

[smithgp]

Yes, I was seeing that as well when diagnosing it. And, that makes sense that updating the icon tenant to NULL in the database would workaround it, although it doesn't work for my use case (since I want a per-tenant icon available for the operation in each tenant).

From the javascript API available in vRO for vRA and the direct REST api call, I tried to set the tenant to NULL, but it didn't work (i.e. if I pass null/undefined/'' to the tenant arg to the js or REST call, something puts the current tenant name in behind the scenes and it goes into the database). So, there's 2 bugs in there (can't update iconId on operation, and can't make set icon tenant to null from api).

[DanieleUlrich]

since I want a per-tenant icon available for the operation in each tenant

will never work based on the model implemented for XaaS resource actions: if they are generating the icon name from the workflow id with "_icon" as suffix AND the generated id is the primary key of the table, it is not possible to have an entry per tenant.

CREATE TABLE cat_icon 
  ( 
     id           CHARACTER VARYING(255) NOT NULL, 
     contenttype  CHARACTER VARYING(255) NOT NULL, 
     filename     CHARACTER VARYING(255) NOT NULL, 
     image        OID NOT NULL, 
     subtenant_id CHARACTER VARYING(40), 
     tenant_id    CHARACTER VARYING(255), 
     PRIMARY KEY (id), 
     CONSTRAINT cat_icon__subtenant_id__cat_subtenant__id__fkey FOREIGN KEY ( 
     subtenant_id) REFERENCES "cat_subtenant" ("id"), 
     CONSTRAINT cat_icon__tenant_id__cat_tenant__id__fkey FOREIGN KEY (tenant_id 
     ) REFERENCES "cat_tenant" ("id") 
  ); 

How useful, however, it is to have different icons for the same workflow is another question. We're acting as service provider so yes, I can imagine that it could be a customer's wish to do so, but sometimes I really like it to have a reason to just say no :smileylaugh:.

[smithgp]

Yep, using the vRA UI screens to create actions (and apparently the CloudClient), it will never work because the UI always uses <vro-workflow-id>_icon for the icon id on the resource operation and that won't work across tenants.

The original issue I had was when I was using vRA's api in vRO (which uses the vRA REST api behind the scenes) to generate a unique icon id (instead of <vro-workflow-id>_icon) on each resource operation in each tenant; I was doing that in vRA 7.1 and it worked fine (both in setting the icon id and in the vRA ui), but it did require writing some reasonably complicated javascript in a vRO workflow to call the various vRA actions and methods. In vRA 7.2, I couldn't set the resource operation icon id because of the 'Shared' vs. 'Built-in' change -- I get a 403 permission denied when I try to change the operation icon id from <vro-workflow-id>_icon to something unique.

[DanieleUlrich]

OK, Greg, I think there is some room for improvement, to my mind there should be both: a default icon per workflow and the possibility to override it with a custom icon per tenant what would require that this icon has an UUID of its own.

I’ll try to file this as bug and I hope we’ll get an answer asap.

So for me your question looks analyzed in depth and answered for now.

[smithgp]

This is in the Knowledge Base now as a known 7.2 bug -- https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=21490...