Ensure that the VIC UI Plugin works when multiple VIC OVAs are present in a vCenter

[zjs]

As described in #740, there are cases where a user may deploy multiple VIC OVAs within a single vCenter.

We should ensure that coupling the lifecycle of the VIC UI Plugin with the lifecycle of the VIC OVA does not prevent us from supporting this use case.

Of specific concern is the logic that the UI Plugin uses to find the VIC OVA; it may not behave as expected in the presence of multiple VIC OVAs of different versions.

While vic-machine-server is stateless, and therefore any vic-machine-server instance of the appropriate version should work with the UI plugin, we should be mindful of other considerations. For example, knowing which instance is used may be important to allow failures to be debugged, using a consistent instance may be necessary to avoid issues related to acceptance of self-signed certificates, and we should be mindful of other differences between VIC OVAs if several are present (power state, network topology, etc.).

In addition to necessary investigation, we should demonstrate that this works via an automated test.

While some of this work is necessary for #1432, it may be possible to defer specific tasks on a case-by-case basis.

[stuclem]

There is some discussion of how the plug-in deals with a multi-VC environment in vmware/vic-ui#365. This relates to the old, script-based plug-in installation, rather than to the auto-installation, but might be relevant.

[zjs]

Minor note: It is necessary to support downgrade of the vic-ui plugin (to rollback in the case of a failed OVA upgrade), but we probably want that to be somehow explicit so that initializing an old OVA does not cause the downgrade to happen.

[zjs]

After discussion with @hickeng, I think there are several things we can do here:

1. Give the user more choice about whether to install the UI plugins.
   • For 1.4.3, provide a checkbox, which is checked by default, on the OVA initialization page: "Install UI Plugin". If this is not checked, do not install/reinstall the UI plugins.
     • This involves changes to the "Getting Started" UI and API, changes to the initialization code which installs the plugin (to make the process conditional), and additional tests.
   • For 1.4.3, provide an option, which is enabled by default, during the OVA upgrade: "Upgrade UI Plugin". If this is not selected, do not upgrade the UI plugins.
     • This involves changes to the upgrade script user interaction, changes to the upgrade code which upgrades the plugin (to make the process conditional), and additional tests.
   • Eventually, provide some sort of warning if downgrade of the UI plugin will occur.
2. Improve the plugin's behavior when multiple OVAs are detected.
   • For 1.4.3, do not attempt to connect to OVAs which are not powered on. Display a clear error message if OVAs are present, but none are powered on.
     • This involves changes to the plugin's OVA lookup logic, changes to the plugin's error handling, and additional tests.
   • Eventually, only use OVAs with an API server that implements a compatible version of the VCH Management API. Display a clear error message if OVAs are present, but none are compatible.
3. Provide the plugin user with more visibility into the available plugins.
   • For 1.4.3, display the version of the OVA the plugin is communicating with on the plugin's "summary" page.
     • This involves changes to the plugin's UI.
   • Eventually, this likely involves replacing the initial landing page of the plugin which currently has a single-row datagrid. (Or removing that page entirely and adding a tab on the next page of the plugin, between "Summary" and "Container Hosts" which provides information about the available OVAs.)
   • Eventually, this allows a user to select which of several compatible OVAs should be used.

[renmaosheng]

moving to 'not ready', we should triage this Epic with James, what kind of multiple OVA use scenario we should support in VIC 1.5.