Tasks names are shown as <taskname>.label

[KobiT118]

Hello,
I have a vSphere plugin created a while ago.
It works fine except for the tasks' labels in the 'Tasks' window and the 'Recent Tasks' frame.
All of its tasks are shown as <task-name>.label and not as the actual tasks' names.
It happens in both web clients (flex and html 5) for all tested vSphere versions (6.0, 6.5, 6.7u1).
It is worth mentioning we've seen cases in which our plugin's tasks are shown correctly and it seems to be non consistent.

I went through the web and read many discussions of people who had similar issues but non of the suggested solusions worked for me:

https://communities.vmware.com/thread/513423 is the closest description of my problem.
I followed Peter Ivanov's instructions (on vSphere 6.7u1).
My plugin is not shown in /etc/vmware/vsphere-client/cmCatalog or /etc/vmware/vsphere-ui/cmCatalog/

I entered https://<vc-ip>/cm/mob/?moid=ServiceManager and searched the suggested xml criteria. My plugin did not show there.

service-control --status result is:
Stopped:
 vmcam vmware-imagebuilder vmware-mbcs vmware-netdumper vmware-rbd-watchdog vmware-vcha vsan-dps
Running:
 applmgmt lwsmd pschealth vmafdd vmcad vmdird vmdnsd vmonapi vmware-analytics vmware-cis-license vmware-cm vmware-content-library vmware-eam vmware-perfcharts vmware-pod vmware-postgres-archiver vmware-rhttpproxy vmware-sca vmware-sps vmware-statsmonitor vmware-sts-idmd vmware-stsd vmware-updatemgr vmware-vapi-endpoint vmware-vmon vmware-vpostgres vmware-vpxd vmware-vpxd-svcs vmware-vsan-health vmware-vsm vsphere-client vsphere-ui

my plugin is called powertools.
vsphere_client_virgo.log is attached.

What am I missing?
I'm willing to provide any required additional information.

[KobiT118]

Sorry, the uploaded log was the last one and did not contain the relevant information.

Here's the log from the first installation of the plugin on a fresh vSphere.

[_vladi_]

Hi,

The client log seems fine - plugin is correctly deployed.

Tasks are not integral part of the plugin but are normally a recommended addition to the partner solution itself. Given the cmCatalog does not have your plugin resource bundle you should be mostly looking at the vCenter registration. A vCenter extension has a number of properties. Some of the important ones are the "client" and the "server" info which you have already set because they deal with the plugin itself (which is successfully installed).

If you need to have task tracking you should also set the following data in the vCenter extension (see API https://code.vmware.com/apis/196/vsphere/doc/vim.Extension.html😞

1. taskList with all task types your solution is creating.
2. resourceList with all localization data / strings per locale. Tasks normally declare the following keys:
   1. Name: <full-task-name>.label = My Task Name
   2. Description: <full-task-name>.summary = My Task Description
      Note that the API is very opinionated with regards to 2.1 and 2.2 and require that you specify the keys with full task name + .label or .summary in order to be picked up by the UI.
3. (Optional) faultList with possible custom defined error messages in the form:
   1. Message: <full-fault-class-name>.summary = My Custom Error Message

The issues you are facing indicate likely missing 2.1 and/or 2.2.

Note also that 1. and 3. above can be inspected in the MOB: https://<vc-ip>/cm/mob/?moid=ExtensionManager but 2. will not be visible there although it was added. Instead, 2. can be inspected in the catalogs of the LocalizationManager for each locale: https://<vc-ip>/cm/mob/?moid=LocalizationManager

Given these specifics I guess this is worth a blog post some time soon

Cheers,

Vladi

[KobiT118]

Thank you for the answer.
In the MOB url addresses you provided, is the cm part redundant? It only works for me without this part (e.g. : https://<vc-ip>/mob/?moid=ExtensionManager)
Unfortunately your suggestions did not work for me as all of the plugin's data seems to be correct:
1. taskList contains the right information in ExtensionManager in MOB (without cm part)

(see attached picture 1)

2. I can see my plugin in the LocalizationManager in the MOB (again, without the cm part). The catalogUri refers to task.vmsg file I found in /etc/vmware-vpx/extensions/com.infinidat.powertools.develop.host.ci012/locale/en/task.vms
and can also be accessed via the https://<vc-ip>/<catalogUri> shown in the picture.

Its content is as follows:
signature = "sIgNaTuRe"
com.infinidat.powertools.develop.host.ci012.expose_infinidat_snapshot.label = "Expose INFINIDAT Snapshot"
com.infinidat.powertools.develop.host.ci012.volume_provisioning.label = "Volume provisioning"
com.infinidat.powertools.develop.host.ci012.restore_infinidat_snapshot.label = "Restore INFINIDAT Snapshot"
com.infinidat.powertools.develop.host.ci012.volume_resize.label = "Volume resize"
com.infinidat.powertools.develop.host.ci012.volume_map.label = "Volume map"
com.infinidat.powertools.develop.host.ci012.volume_unmap.label = "Volume unmap"
com.infinidat.powertools.develop.host.ci012.create_infinidat_snapshot.label = "Create INFINIDAT Snapshot"
com.infinidat.powertools.develop.host.ci012.expose_infinidat_snapshot.summary = "Expose INFINIDAT Snapshot"
com.infinidat.powertools.develop.host.ci012.volume_provisioning.summary = "Volume provisioning"
com.infinidat.powertools.develop.host.ci012.restore_infinidat_snapshot.summary = "Restore INFINIDAT Snapshot"
com.infinidat.powertools.develop.host.ci012.volume_resize.summary = "Volume resize"
com.infinidat.powertools.develop.host.ci012.volume_map.summary = "Volume map"
com.infinidat.powertools.develop.host.ci012.volume_unmap.summary = "Volume unmap"
com.infinidat.powertools.develop.host.ci012.create_infinidat_snapshot.summary = "Create INFINIDAT Snapshot"

(see attached picture 2)

3. We do not define the optional faultList.

I appreciate your help.
Do you have any other ideas?
Kobi

[_vladi_]

Hi Kobi,

There are multiple MOBs:

• /mob is for the current vCenter Server MOB
• /cm/mob is for the legacy MOB of the ComponentManager which spans across all linked vCenter Servers
• /lookupservice/mob is for the MOB of the LookupService (successor of ComponentManager) which also spans across all linked vCenter Servers

Tasks are uniquely created per-vCenter Server so you have used the right one: /mob

The setup with your tasks seems correct. Next thing to check is if you can find the catalog with this ID and localization strings in /etc/vmware/vsphere-ui/cmCatalog

If yes, it might be some weird formatting requirement (try removing underscores?).

Please let us know how it goes. We will also try to reproduce it with the data provided. Thanks!

Cheers,

Vladi

[KobiT118]

Hi Vladi,

There is no catalog of my extension in /etc/vmware/vsphere-ui/cmCatalog:

root@vcenter-ci15 [ ~ ]# ls  /etc/vmware/vsphere-ui/cmCatalog

com.vmware.applmgmt.applmgmt.zip       com.vmware.cis.cs.license.zip             com.vmware.ph.phservice.zip

com.vmware.cis.cis.cls.zip             com.vmware.cis.cs.perfcharts.zip          com.vmware.rbd.rbd.zip

com.vmware.cis.cis.vmonapi.zip         com.vmware.cis.cs.vapi.zip                com.vmware.vcIntegrity.vcIntegrity.zip

com.vmware.cis.com.vmware.vsan.dp.zip  com.vmware.cis.cs.vsm.zip                 com.vmware.vim.sms.sms.zip

com.vmware.cis.cs.authorization.zip    com.vmware.cis.messagebus.config.zip      com.vmware.vsan-health.vsan-health.zip

com.vmware.cis.cs.eam.zip              com.vmware.cis.vcenterserver.zip          com.vmware.vum.client.zip

com.vmware.cis.cs.inventory.zip        com.vmware.cis.vsphereclient.zip

com.vmware.cis.cs.keyvalue.zip         com.vmware.imagebuilder.imagebuilder.zip

Thanks,

Kobi.

root@vcenter-ci15 [ ~ ]# ls  /etc/vmware/vsphere-ui/cmCatalog

com.vmware.applmgmt.applmgmt.zip       com.vmware.cis.cs.license.zip             com.vmware.ph.phservice.zip

com.vmware.cis.cis.cls.zip             com.vmware.cis.cs.perfcharts.zip          com.vmware.rbd.rbd.zip

com.vmware.cis.cis.vmonapi.zip         com.vmware.cis.cs.vapi.zip                com.vmware.vcIntegrity.vcIntegrity.zip

com.vmware.cis.com.vmware.vsan.dp.zip  com.vmware.cis.cs.vsm.zip                 com.vmware.vim.sms.sms.zip

com.vmware.cis.cs.authorization.zip    com.vmware.cis.messagebus.config.zip      com.vmware.vsan-health.vsan-health.zip

com.vmware.cis.cs.eam.zip              com.vmware.cis.vcenterserver.zip          com.vmware.vum.client.zip

com.vmware.cis.cs.inventory.zip        com.vmware.cis.vsphereclient.zip

com.vmware.cis.cs.keyvalue.zip         com.vmware.imagebuilder.imagebuilder.zip

[_vladi_]

Hi Kobi,

I had a deeper look at the details provided.

The H5 Client logs are from 2019-12-23. Unfortunately based on the screenshots the extension and the localization files have been registered on 2020-01-01 which is later.

Generally the Client downloads the resource bundles on startup and updates with any new bundles on user login so I would like to check what the H5 Client did after the registration. Could you please provide the latest vsphere_client_virgo.log after the time of registration?

Thanks,

Vladi

[KobiT118]

Hi Vladi,

This is because it's our development env.
I need to recreate the setup every time from scratch.

But okay,
I unregistered our extension via MOB and restarted vsphere-ui to start from clean state.
Then started tailing vsphere_client_virgo.log, registered our extension and created a task that resulted in the <taskname>.label line in 'Recent Tasks'
The relevant part from vsphere_client_virgo.log is attached.

Thanks,
Kobi

This is because it's our development env.

I need to recreate the setup every time from scratch.

But okay,

I unregistered our extension via MOB and restarted vsphere-ui to start from clean state.

Then started tailing vsphere_client_virgo.log, registered our extension and created a task that resulted in the <taskname>.label line in 'Recent Tasks'

The relevant part from vsphere_client_virgo.log is attached.

Thanks,

Kobi

[_vladi_]

Hi Kobi,

I see the following logs:

[2020-01-08T13:48:25.724Z] [INFO ] cm-catalog-manager-pool-124  70000179 100018 200002 com.vmware.vise.vim.lookup.LsCatalogManager                       detectServiceProviders took (ms):514

[2020-01-08T13:48:25.744Z] [INFO ] cm-catalog-manager-pool-124  70000179 100018 200002 com.vmware.vise.vim.lookup.LsCatalogManager                       No new locales or service infos to download.

This is surprising given the registration should be there. I will try to reproduce this in house. Thanks!

Cheers,
Vladi

[KobiT118]

Thanks Vladi,

I'll be waiting.

Kobi.

[KobiT118]

Could the reason that no new locales found be that the extension was already registered before so the locale files were already downloaded? Even though I unregistered it, the files might already have been there.

In fact, the locale file exists in /etc/vmware-vpx/extensions/com.infinidat.powertools.develop.host.ci013/locale/en/task.vmsg

In addition when I go to <vc>/mob/?moid=TaskManager I see my tasks and clicking on them shows their labels and summaries (see pics)

[_vladi_]

Hi Kobi,

From all this info it seems strange that you are getting the catalogs only in the vmware-vpx folder but not in the cmCatalog. This makes me think that the registered localization bundles have not been attached to the actual extension.

Still need to try this out locally but in the meantime could you please let me know or provide a code snippet of how the vCenter extension registration is done (especially interested in how the resourceList is set and how the bundles get registered) ?

Thanks.

Cheers,

Vladi

[KobiT118]

Hi Vladi,

Here's a snippet of our registration of the extension:
https://drive.google.com/file/d/1n5gk1VEt7RcamtkdLhKwZxqOLNaSmOgT/view?usp=sharing

Thanks, 

Kobi.

[_vladi_]

Hey Kobi, this looks good.

A trivial follow up question: Are you restarting the vsphere-ui service after updating the extension?

[KobiT118]

I tried that too, running

service-control --stop vsphere-ui
service-control --start vsphere-ui

but it doesn't seem to have any effect on my issue.

service-control --stop vsphere-ui

service-control --start vsphere-ui

[stoevm]

Hi Kobi,

A version of an SDK sample will be available in a future release where the Task creation is demonstrated in details.
Keeping this in mind I tried to reproduce the scenario described in this communication but I did not succeed .
I tryed with task keys like `com.infinidat.powertools.develop.host.ci012.expose_infinidat_snapshot` but did not succeed to break it.

Few things to have in mind, which were new to me as well:

1) The vSphere Client downloads new catalogs in ...\vsphere-client\cmCatalog on startup, meaning that the sequence of testing the tasks localization is as follows:
    - stop the vSphere Client
    - register the plug-in.
    - start the vSphere Client

2) The vSphere Client caches the catalogs, namely after the plugin has been registered with an update on the localization strings for the tasks,
       the catalogs must be deleted from ...\vsphere-client\cmCatalog.

3) The creation of the task is done with some_task_id, and the localization strings are created with some_task_id.label and some_task_id.summary (just writing it here I know that this is known info.)

If you can create a simple reproducable version of the SDK html-sample, which I can deploy in our test environments and verify, I will be more than happy to test it out and
root cause the problem.

Best,
Martin.