Need help in Plugin Extension Version specification

[kumartade]

Hi Team,

we want to adopt a new specification for version numbering of our plugin. We want to specify the version numbering as "A.B.C.D.E" for example “9.6.0.0000.1”, “9.6.1.0100.1”, “9.6.1.0101.1”, “9.6.1.0001.1”. where E=build version, then how does this version work for:

1. Fresh plugin extension registration
2. Upgrade plugin extension from previous release version TO next release version
3. Upgrade plugin extension from nightly/dev build TO nightly/dev build
4. Criteria of version string for plugin extension upgrade?

When I refer the exisitng vSphere plugin, I'm seeing two version numbers in the mob.

When I see the VC packages, it seems the virgo server is taking the Version#1 as the criteria to download the plugin package to vCenter server.

1. In my obsevation, I 'm assuming that vSphere mob will blindly fetch the version for mob and downloads the same to "vc-packages" if the same version is not found in the directory.

vSphere doesn't do any comparision like 6.6.1.20000>6.6.1.19998. Please confirm on this?

2. What is the significance of Version#1 and Version#2? Which one is used for what?

Thanks,

Kumar T.

[kumartade]

Looking for some info here.

[Vladimir Velikov]

Hi Kumar,

Let me first provide more details on the topic which will help answering your specific questions.

vCenter ExtensionManager supports adding extensions to the vCenter which can be UI plugins but can also have other purposes. You can uniquely identify a plugin extension by the existence of ExtensionClientInfo - if this is not set the extension does not represent a plugin. For example your first screenshot shows the VSAN plugin extension while the second one shows an additional VSAN extension that defines more Task types (used by the VSAN service or plugin).

vSphere Client fetches only the vCenter plugin extensions upon user login.

A vCenter cannot have duplicate extension IDs so it is not possible to have multiple versions of the same plugin registered with a single vCenter. That said, it is possible to have a multi-vCenter environment in Enhanced Linked Mode or Hybrid Linked Mode which contains multiple versions of the same plugin.

For example: vCenter1 with plugin "P" version 1.0 and vCenter2 with plugin "P" version 2.0.

Whenever you log into any vSphere Client connected to this environment it will download both plugin versions 1.0 and 2.0.

• If 1.0 comes first it is deployed. When 2.0 comes, the Client would see that the version is higher, undeploy 1.0 and deploy 2.0
• If 2.0 comes first it is deployed. When 1.0 comes, the Client would see that the version is lower and ignore 1.0.

Please note this behavior is applicable to Local plugin architecture.

Remote plugin architecture has multi-version support which means that in the above scenario both 1.0 and 2.0 will be operational on the environment - which one is used depends on the selected context in the inventory or the user selection (for global plugin views).

Based on the above here are answers to your questions:

1. The statement is not correct - there is a very explicit vSphere Client-side version check.

2. The vSphere Client uses the version defined in ExtensionClientInfo.

Hope this helps.

Cheers,

Vladi

[Vladimir Velikov]

I missed one point: The vSphere Client versioning check for plugins is more opinionated than the vCenter Extension API.

Valid versions are in the form "A.B.C.D" where you can skip any of B, C and D.

This means "A.B.C.D.E" will not work as a versioning scheme. Please come up with a scheme that fits the above rules.

Cheers,

Vladi

[kumartade]

Thanks for the detailed info on plugin registration internals.:smileyhappy:

I have few queries:

1. Currently, to update our plugin existing plugin, we call unregister/remove-plugin and then re-register plugin with new version.

Is this recommended way? What is the recommended approach?

2. Every time we update a plugin we see multiple plugin folders in vc_packages. we have to delete the plugin folders manually as clean-up process.

Can we not have neater way of doing this by using VMware provided mechanism to have smooth upgrade experience?

3. Does Version number A.B.C.D have any min or max integer range?

[LokeshN]

1. Currently, to update our plugin existing plugin, we call unregister/remove-plugin and then re-register plugin with new version. Is this recommended way? What is the recommended approach?
In the context of local plugin, to update the plugin bits the version of the new plugin should be greater than the existing version. If the version is greater, the framework takes care of un-deploying the existing one and deploying the new one. If the version is lower or same, then the approach you are using is correct.

2. Every time we update a plugin we see multiple plugin folders in vc_packages. we have to delete the plugin folders manually as clean-up process.
Can we not have neater way of doing this by using VMware provided mechanism to have smooth upgrade experience?
If the version of the newly updated plugin is lower than the existing plugin then eventhough the new plugin is downloaded, it is not deployed and left as is.
This could be one of reasons for the unused plugin packages in vc-packages folder.

3. Does Version number A.B.C.D have any min or max integer range?
The minimum value for these should be >=0 and max is Integer.MAX_VALUE.

[LokeshN]

Hi Kumar,

I have provided the answers for your questions in the above thread.

Thanks,
Lokesh 

[LokeshN]

Hi Kumar,

Regarding point 2. Every time we update a plugin we see multiple plugin folders in vc_packages. we have to delete the plugin folders manually as clean-up process.
Can we not have neater way of doing this by using VMware provided mechanism to have smooth upgrade experience?
- I missed mentioning about a feature where the framework does the cleanup of the unused plugin packages in the disk. This feature is introduced in 6.7U1 and 6.5U2.

Thanks,
Lokesh

[kumartade]

Thanks for the inputs lokesh,