Dynamic Plugins - Round 3

Problem:

Console provides support UI for operators which is dynamically enabled when the operator is installed; by using feature flags against presence of CRDs. While operators have their own release cadence separately from OpenShift which makes for alignment of UI to API difficult. As new features are released for the operator, the UI becomes out of sync with APIs and customers must wait till the following OpenShift release to get any new UI.

Goal:

• Create an extensibility mechanism which allows Red Hat operators to build and package their own UI that extends the console.
• Make console extensible in areas required to support the needs of contributing plugins.

Why is it important?

• Allows an operator to maintain their own UI and release at their own cadence.
• Alleviates the pressure on console to deliver UI features for multiple operators within a release.

Use cases:

1. Serverless / Pipelines / Helm to contribute resource details pages, import flows, topology visuals etc...

Acceptance criteria:

1. Red Hat Operator can build their own UI which is deployed alongside the operator and extend the dev-console
   1. objective is to get to a point where it is possible to accomplish this however code will not be moved to a separate repository, nor deployed by an operator
2. New extensions for console to allow operators to extend the various areas of console needed in order to provide the proper user experience.
3. Enable operators to override the static built in support, and supply their own UI

Dependencies (External/Internal):

Design Artifacts:

Console extensions:
https://docs.google.com/document/d/1HW5_cl6cOX5P14PQN-1_8c60o9dMY6HbFDRftH6aTno/edit

Dynamic Plugins:
https://docs.google.com/document/d/19BAFo_8BtMZVvKsU-bE61bZpSydeYONkCMWntMU9NgE/edit

Enhancement proposal:
https://github.com/openshift/enhancements/pull/441

Exploration:

Note:

• plugin framework covered by another epic
• out of scope:
  • moving plugins to separate git repository