Feature Overview

This feature comprises multiple parts and will span multiple releases with each subcomponent shipped at different times:

• Start conversion of the Admin console to a plugin 

• Migrate Admin and Dev plugins from static to dynamic plugins

• Migrate static plugins to dynamic- starting with plugins owned by the Admin team 

• Work towards migrating all static plugins to dynamic gradually in collaboration with other teams 

These goals work toward the business strategy to stabilize the platform, create a foundation of hybrid cloud experiences and self-managed, self-healing clusters thus enabling applications that scale.

Goals

The main goals for this release are :

• Migrate static plugins to dynamic and to make Admin and Dev perspectives Dynamic Plugins so internal teams can scale with stability.
• Remove burden from internal teams and empowering users to architect their experiences within defined parameters and dependency on release cadences.
• Enable users who want to replace the Console UI to be supported on so that they can customize their user experience while still being hosted on the console.
• In order to provide support for various use cases: Admin needs to become a plugin and the Admin and Dev need to be migrated from Static to Dynamic to create the Console Framework.

How are we impacted without this Feature?

• Without this Console Framework feature today, UI features are limited to release cycles, and the UI is limited to whatever the console automatically provides. With this feature, internal and external teams are liberated from these restrictions.
• Customers are enabled to have a tailored unique customer experience that may increase stickiness. Internal teams have a stable foundation to scale when not limited to a mono repository and have less burden on Operators.

Requirements - Parameters for determining “done”

 Use Cases

• Internal Static teams -> Dynamic:
  • With Static plugins, If Kubevirt is installed in the cluster and the operator is upgraded to a newer version, the console UI is not ready to interact with the console without rebuilding and redeploying. Alternatively, with Dynamic plugins, one can bypass this and release operators on their own cadence, with their own UI according to each individual team's needs.
•  Users who want to build standalone UIs 
  • Security Operator wants to create easier access to a dashboard for monitoring the security of their clusters ->  They are able to accomplish their goal with Dynamic Plugins by adding a security cluster navigation item that takes them to a telemetry dashboard.

C.R.H.C use cases?

PM: Ali Mobrem??, UX: Mary Clarke, Arch: Jessica Forrester

Admin use cases? 

PM: Ali Mobrem, UX: Colleen Hart, Arch: Sam Padgett

Developer/DevOps use cases? 

PM: Serena Nichols, UX: Beau Morley, Arch: Christian Vogt

Questions to answer…

How  will users interact with this feature:

• Customers will create customized UI experiences built on the Console on demand.
• Internal teams will create a stable scaling experience for their own and other internal teams and relieve burden on Operators.

Out of Scope

• Extension support for all known use cases. 
• Dev perspective - support parity with what we have today
• Current App focused needs and multi clusters 
• App studio development

 Background, and strategic fit

 What do teams need to know and address- 

• Current needs are to separate plugins from mono repo to their own repositories and to resolve experimental technical gaps 
• We need to address how to effectively share code and reuse code from the same repo one is exiting from
• Priority is needed across plugins as every plugin has different complexity
• We need to rearrange the SDK package into NPS.js for code sharing- to extract it so it is usable in other applications
• Console Frameworks will form the foundation of Cloud.redhat.com and will be the goto framework for building UIs both internally and externally

Key Stakeholders of the Console Framework:

• Design, Use Cases & User Flows -> Collaborate with your UI/UX Lead & PM
• Roadmap, Requirements, and Strategy -> Collaborate with your PM
• Extension Points, Architecture, Tech Needs/ Roadblocks ->  Collaborate with your Engineering Lead, Architect & PM

Static Plugin status across groups  :

Static plugins that need to convert to dynamic plugins:

 Serverless, Pipelines, OCS, CSO, RHOAS (Managed Kafka), Dev Console, GitOps, Helm, Insights, metal3, OLM, CNV

Not static plugins: Augment the OS console 

 Web Terminal, CRW/Che, Kata, Service Mesh, Service Binding, Admin 

Planning to augment the OS console:

Cryostat, Managed Services (DBaaS), other RHOAS options, possibly RHODS, Shipwright Builds, ACM

 Assumptions

Assumptions on Dependencies and People Resources-

• Because the console is historically made up of static plugins, to make the Console fully Dynamic all currently static teams Internal & External teams need to prioritize and work together on this mutual initiative to make the OCP fully dynamic, functional, stable, and beneficial for all internal and external teams.
• Externally partners have expressed interest in customizing their UI for their clients and engaging with a demo version of the product release. It is therefore assumed that the Console Framework will be in high demand and can increase stickiness.

 Documentation Considerations

Educational or reference material (docs) is required to support this product feature:

• List of user flows from internal teams and requirements needed to make Dynamic Plugin migration possible across teams
• User facing documentation and blogs discussing Dynamic Plugins and outlining what you can do with them and how you can enable them
• Enablement guides for internal teams including diagrams and architecture 
• A Guide of parameters of what can and can’t be customized (for branding consistency purposes and security)

 Roadmap - Future Vision Goals

• Enable framework for 3rd Party ISV and Customer Plugins
• Console Framework positioned as the foundation of Cloud.redhat.com
• Console Framework becomes the go-to framework for building custom UI’s at Red Hat
• Auto-recommended UI templates per use case based on telemetry and tracking usage data on OCP