vSphere plugin third-party library isolation compatibility

[ChrisSmith2]

Following the 7.0U3 GA SDK announcement, we've followed the steps in the ""Local Plugins: Third-party library isolation" guide to test third-party library isolation. We have several questions that don't seem to be addressed in the document:

1) The document states that "local plugin will be turned off by default" on 7.0U3, and "on from the next major release" - is there an actual setting on the VCSA that can be enabled/disabled? The only VCSA settings described in the document appear to be for debugging.

2) The step-by-step guide for VCSA setup describes modifying a VCSA to be a test environment, and making a change to the plugin's manifest directly on the test VCSA. The steps then end with just "17. Make the necessary changes to your build.". If the manifest change is made to the deployable plugin package, will this then always run as an isolated plugin on any VCSA running 7.0U3 or later (without any modifications to the VCSA)?

3) With the manifest change and necessary bundles added to the package, the plugin works in the test environment. However, it is *not* compatible with older VCSAs (e.g. 6.7.0.48000) - the plugin fails to load with an error "custom WebApplicationContext class [org.eclipse.virgo.web.dm.ServerOsgiBundleXmlWebApplicationContext] is not of type ConfigurableWebApplicationContext". Removing the "org.apache.servicemix.bundles.*" bundles from the package fixes this issue. There is nothing in the document addressing back-compatibility; is this expected at this time, and something that will be fixed by VMware before plugins should be released in isolated mode? If not, can you provide instructions/guidance to ensure plugins are back-compatible across all currently-supported vSphere versions?

[stoevm]

Hi Chris,

Just to be on the same page, a documentation about the local plugin isolation was published on the vSphere Client SDK page, namely
https://vdc-download.vmware.com/vmwb-repository/dcr-public/77dd6491-bb96-47f3-8c2e-a5a4655f078b/fed0...

Answers to the questions:
1) Yes, the idea of the osgi.fullIsolation.debug=true flag is to enable the isolation on a specific environment and to test your local plugin. The isolation in hand will be enabled by default on a subsequent major release.
2) Yes, it will be enabled by default on a subsequent major release.
3) The next major release has increased security requirements, these requirements are a breaking change for local plugins due to the limitations of the Local plugin architecture. Note that the next major release does not introduce additional security requirements for the remote plugin architecture.
The local plugin isolation document is still an early announcement and we are going to update the docs with more details.

Best Regards,
Martin

[ChrisSmith2]

Yes, that is the document that I was referring to.

Your answers still aren't clear to me. On a clean install of VCSA 7.0U3 (without modifications), if a plugin package includes the 'vsphere-ui-dependencies-available="false"' line, will it run in isolated mode or non-isolated mode? Your answer to 1) implies no, but your answer to 2) says yes...

There is no indication in the document that this solution isn't completely finalised, and that these steps should *not* be used for a production plugin at this time.

I understand that breaking changes are sometimes necessary to address security issues. However, in the past, when breaking changes have been introduced it has always been possible to update plugin packages to maintain back-compatibility with prior vCenter releases (e.g. the "Upgrading Your Plug-in To Maintain Compatibility with vSphere Client SDK 6.7" guidance).

To be clear - the key question is whether or not it will be possible to have a single plugin package that is compatible with both vNext and 7.0 (and earlier)?

If there is no solution to the Spring library conflicts and plugin compatibility is mutually exclusive between 7.0 and vNext, such that a single plugin package *cannot* be made to work on both, that is going to be a major pain point for both plugin developers and customers - they will have to maintain and distribute two different versions, and customers will have issues installing the incorrect versions. If the core Spring libraries are fundamentally incompatible, I can see several options that could be used in your plugin packaging to handle this back-compatibility case and minimise this concern (e.g. having a specific sub-folder in the ZIP for isolation-only JARs that wouldn't be loaded by existing vCenter builds).

Until VMware provide a viable migration path for local plugins that do not have an existing external VM/appliance, moving to the "remote plugin architecture" is not an option for us (or many other existing local plugins).