Uploaded image for project: 'OpenShift Top Level Product Strategy'
  1. OpenShift Top Level Product Strategy
  2. OCPPLAN-8029

Console: Dynamic Plugin Framework

XMLWordPrintable

    • No
    • 0% To Do, 20% In Progress, 80% Done

      Feature Overview

      Plugin teams need a mechanism to extend the OCP console that is decoupled enough so they can deliver at the cadence of their projects and not be forced in to the OCP Console release timelines.

      The OCP Console Dynamic Plugin Framework will enable all our plugin teams to do the following:

      • Extend the Console
      • Deliver UI code with their Operator
      • Work in their own git Repo
      • Deliver at their own cadence

      Goals

        • Operators can deliver console plugins separate from the console image and update plugins when the operator updates.
        • The dynamic plugin API is similar to the static plugin API to ease migration.
        • Plugins can use shared console components such as list and details page components.
        • Shared components from core will be part of a well-defined plugin API.
        • Plugins can use Patternfly 4 components.
        • Cluster admins control what plugins are enabled.
        • Misbehaving plugins should not break console.
        • Existing static plugins are not affected and will continue to work as expected.

      Out of Scope

        • Initially we don't plan to make this a public API. The target use is for Red Hat operators. We might reevaluate later when dynamic plugins are more mature.
        • We can't avoid breaking changes in console dependencies such as Patternfly even if we don't break the console plugin API itself. We'll need a way for plugins to declare compatibility.
        • Plugins won't be sandboxed. They will have full JavaScript access to the DOM and network. Plugins won't be enabled by default, however. A cluster admin will need to enable the plugin.
        • This proposal does not cover allowing plugins to contribute backend console endpoints.

       

      Requirements

       

      Requirement Notes isMvp?
       UI to enable and disable plugins    YES 
       Dynamic Plugin Framework in place    YES 
      Testing Infra up and running   YES 
       Docs and read me for creating and testing Plugins    YES 
      CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
      Release Technical Enablement Provide necessary release enablement details and documents. YES

       
       Documentation Considerations

      Questions to be addressed:

      • What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
      • Does this feature have doc impact?  
      • New Content, Updates to existing content,  Release Note, or No Doc Impact
      • If unsure and no Technical Writer is available, please contact Content Strategy.
      • What concepts do customers need to understand to be successful in [action]?
      • How do we expect customers will use the feature? For what purpose(s)?
      • What reference material might a customer want/need to complete [action]?
      • Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
      • What is the doc impact (New Content, Updates to existing content, or Release Note)?

              spadgett@redhat.com Samuel Padgett
              amobrem Ali Mobrem
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: