Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Decouple] Add new core service to check cross compatibility of plugins #4903

Open
manasvinibs opened this issue Sep 1, 2023 · 0 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@manasvinibs
Copy link
Member

Overview:

OpenSearch Dashboards plugin will require OpenSearch counterpart for them to function correctly. Currently, through manifest configuration plugins can define the requiredEnginePlugins and during the plugin bootstrap, Opensearch Dashboards will validate if the required plugin dependencies are satisfied or not. In current state, we do not stop the bootstrapping of plugins if a dependency is not satisfied and simply log the warning for the system admin to know the state of the plugin.

As a next step to this feature, plugins should be able to define the range of the versions they are compatible with their engine counterpart plugins. This will allow Dashboards plugins to decouple from its counterpart engine plugin without being tightly coupled on the version.

Requirement:

Export feature that plugins can extend to decide what they want to do if their engine plugin counterpart is not installed or has incompatible version.

Design:

Following changes are made to add this feature:

Add new core service in the Opensearch Dashboards core/server called CrossCompatibilityService -

  • This service will expose APIs which plugins can extend to decide what they want to do if their OpenSearch plugin counterpart is not installed or has incompatible version. The possible actions would be to (NOTE: these are states and not the actual defined names)
    • Plugin can decide if its DISABLED (in the browser but grayed out)
    • Plugin can decide if its LIMITED_FUNCTIONALITY: In todays world, not much difference between this and fully enabled but this can be thought as a singleton boolean that can be accessed by the plugin in their rendering of components that they can access to decide what they want to do in the their component.
    • Plugin can decide if its FULLY_ENABLED
    • Plugin can decide if its DO_NOT_BUNDLE (no longer in the browser)
    • Plugin will be able to write the logic to handle it
    • Plugin can define it's supported versions
      If the user decides to upgrade to OSD but the plugin isn't ready, then the plugin will hook into the above logic that gets executed that follows the above rules to decide how it wants to operates.
  1. CrossCompatibilityServiceStart :
    This will expose function verifyOpenSearchPluginsState() to check if the OpenSearch Dashboards plugin version is compatible with the installed OpenSearch plugin. Dashboards plugin can access this interface during the start phase of plugin lifecycle to invoke the service to check the cross compatibility of plugin during Dashboards runtime.
  2. CrossCompatibilityResult :
    This will encapsulate the Cat plugin API response which includes plugin compatibility state information. This can be further improved to include more information on the cluster/node on which indexes are stored which can be used by plugins to configure their state.
  3. CrossCompatibilityService class :
  • This class contain start() method which returns verifyOpenSearchPluginsState() - Reads the plugin manifest to get the defined required engine dependencies and its version ranges. Returns the plugin with response containing information on if plugin is compatible or not.
  • checkPluginVersionCompatibility() - Verifies if the version range satisfies the installed plugin version
  • isVersionCompatibleOSPluginInstalled() - returns true if plugin is compatible with its engine counter part, else return false.
  • getOpenSearchPlugins() - This function makes API call to Opensearch to read the installed plugins on the cluster.

Further this service can be utilized to expose functions, which does compatibility check of various other parts of the components such as plugins and its OS version, OSD with its OS versions. We can extend the functionality to not just specific to versions but also to add additional criterias to determine compatibility between various components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant