Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-988

Deprecation visuals and notifications/alerts in the console

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • None
    • UX
    • False
    • Hide

      None

      Show
      None
    • False
    • OCPSTRAT-27Operators and Operator Lifecycle Management and Operator Hub
    • 50
    • 50% 50%
    • 0
    • 0

      Feature Overview (aka. Goal Summary)

      OLM users can easily see in the console if an installed operator package is deprecated and learn how to stay within the support boundary by viewing the alerts/notifications that OLM emits, or by reviewing the operator status rendered by the console with visual representation.

      Goals (aka. expected user outcomes)

      • Pre-installation: OLM users can see the deprecation visual representation in the console UI and be warned/discouraged from installing a deprecated package, from deprecated channels, or in a deprecated version, and learn the recommended alternatives to stay within the supported path (with a short description).
      • Post-installation: OLM users can see the deprecation visual representation in the console UI to tell if an installed operator is deprecated entirely, currently subscribed to a deprecated channel, or in a deprecated version, and know the alternatives as in package(s), update channel(s), or version(s) to stay within the support boundary.
      • Post-installation: OLM users can be notified of the deprecation via alerts/notifications in the console UI (and CLI) to tell if an installed operator is in any kind of deprecated state so they can be made aware of this and react with ease.  

      Background

      We have customers (e.g., Citigroup) who have dozens of operators installed in hundreds of clusters.  They are required to conduct audits periodically to determine if all the installed operators are still within the support boundary. 

      Customers will be able to generate an aggregated report centrally with another tooling, such as RHACM, to answer questions such as "How many deprecated operators are in a particular managed cluster?" or "How many deprecated operators are in the cluster fleet in total?"

      In this phase, the focus is on improving the in-cluster user experience (UX) so that a cluster administrator can be notified of deprecation via alerts/notifications and see a visual representation in the console through the extended OLM capabilities.

      Requirements (aka. Acceptance Criteria):

      • Pre-installation: The console can render the deprecation visual representation (as per the OLM Package Server) to discourage users from installing deprecated packages, channels, or versions, and to make them aware of the recommended alternatives to stay within the supported path.
      • Post-installation: The console can render the deprecation visual representation (as per the OLM Subscription API) to warn users against subscribing to or staying with deprecated packages, channels, or versions, and to make them aware of the recommended alternatives to stay within the supported path.
      • Post-installation: OLM emits deprecation alerts/notifications to notify users about operators subscribed to or installed in deprecated packages, channels, or versions.  The console can then render these deprecation alerts/notifications accordingly to make users easily aware of them.
        • Note: a new Prometheus metric ** to indicate if a package, update channel, or version is deprecated in the cluster.  

      Documentation Considerations

      • All the requirements need relevant documentation for users to learn how to learn and react to the deprecated content in the package, subscribed channels, or in an out-of-support version. 

      Related Engineering Briefs/RFCs

      -----

      Use Cases (Optional):

      Include use case diagrams, main success scenarios, alternative flow scenarios. Initial completion during Refinement status.

      Questions to Answer (Optional):

      Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.

      Out of Scope

      High-level list of items that are out of scope. Initial completion during Refinement status.

      Customer Considerations

      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature. Initial completion during Refinement status.

      Interoperability Considerations

      Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.

            rhn-coreos-tunwu Tony Wu
            rhn-coreos-tunwu Tony Wu
            Ali Mobrem
            Xiaoli Tian Xiaoli Tian
            Matthew Werner Matthew Werner
            Eric Rich Eric Rich
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: