Feature Overview (aka. Goal Summary)  

OLM users can stay on the supported path for an installed operator package by 

• seeing if an installed operator package is:
  • deprecated entirely,
  • currently subscribed to a deprecated channel, or
  • currently stays in a deprecated version, and

• also knowing the alternative package or update channel(s) to change to, if provided by the operator authors/package maintainers.

Goals (aka. expected user outcomes)

• Operator package maintainers can mark the entire package, an update channel, or an individual bundle version as deprecated and optionally provide a suggested package, update channel(s), or version(s) for the ongoing update path(s). 

• OLM users can see the deprecation marker/indicator from CLI (and UI in the future) and are discouraged from installing a deprecated package or from deprecated channels. → pre-installation

• OLM users can see the deprecation marker/indicator from CLI (and UI in the future) to tell if an installed operator is deprecated entirely or is currently subscribed to a deprecated channel, and they know the alternative package or update channel(s) to stay on the supported path → post-installation

• Cluster or operator admins can get an aggregated report with another tooling from the deprecation marker/indicator to know centrally from their cluster fleets if any operator package installed was deprecated and out of support.

Requirements (aka. Acceptance Criteria):

• Operator package maintainers can denote deprecation information in file-based catalogs via the catalog templates:
  • the entire package as “deprecated” and optionally provide recommended package(s) with a short description as the alternative in file-based catalogs (e.g., in olm.package) via the catalog templates.
  • an update channel as “deprecated” and optionally provide recommended channel(s) with a short description as the alternative in file-based catalogs (e.g., in olm.channel) via the catalog templates.
  • a specific version as “deprecated” and optionally provide recommended version(s) with a short description as the alternative in file-based catalogs (e.g., via olm.bundle) via the catalog templates.

• Operator package maintainers can denote deprecation information in file-based catalogs via the bundle-based workflow using the current Red Hat build pipeline:
  • the entire package as “deprecated” and optionally provide recommended package(s) with a short description as the alternative in file-based catalogs (e.g., in olm.package) via the bundle-based workflow using the current Red Hat build pipeline.
  • an update channel as “deprecated” and optionally provide recommended channel(s) with a short description as the alternative in file-based catalogs  (e.g., in olm.channel) via the bundle-based workflow using the current Red Hat build pipeline.
  • a specific version as “deprecated” and optionally provide recommended version(s) with a short description as the alternative in file-based catalogs (e.g., via olm.bundle) via the bundle-based workflow using the current Red Hat build pipeline.

• OLM Package Server can serve the “deprecated” information and the optional recommended alternative with a short description of the packages in a catalog.

• A user can get the “deprecated” information via CLI or UI to interact with the OLM Package Server. → Pre-installation.

• OLM Subscription can serve the “deprecated” information and the optional recommended alternative with a short description of the packages in a catalog.
  • A user can get the “deprecated” information via CLI or UI that interacts with the OLM Subscription. → Post-installation.

• OLM exposes the “deprecated” information of a particular operator (i.e., it’s “deprecated entirely” or “subscribing to a deprecated channel”) such that an external tool, such as ACM, can display a report to show “how many deprecated operators" from this particular cluster”, or “how many deprecated operators from the cluster fleet”.
  • Notes:
    • option 1) separated Prometheus metrics to indicate if a package, update channel, or version is deprecated in the cluster.
    • option 2) A note (from the ACM team on Aug 4th):
      • "ACM can query arbitrary object types with some saved searches"
        • Scott Berens: We from the xCM (ACM) Search side, are in full support.

Out of Scope

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

Background

We have customers (e.g., Citigroup) who have dozens of operators installed in hundreds of clusters.  They need to conduct audits periodically to tell if all the installed operators are still within the support boundary.  Currently, there’s no way for them to tell if a particular operator package, or an update channel being subscribed to, or a current running operator version is supported or not.  

OLM extends the support in content deprecation management will enable operator package maintainers to curate this type of information better and benefits the admin types of users of our product.  

Customer Considerations

• Citigroup
• Red Hat Operators/Layered products

Documentation Considerations

• Operator package maintainers need to know how to denote:
  • the entire package as “deprecated” and optionally provide recommended package(s) with a short description as the alternative in file-based catalogs via the catalog templates.
  • an update channel as “deprecated” and optionally provide recommended channel(s) with a short description as the alternative in file-based catalogs via the catalog templates.
  • a specific version as “deprecated” (if not executing a “minor version channel” scheme) and optionally provide recommended version(s) with a short description as the alternative in file-based catalogs via the catalog templates.

• Red Hat internal operator package maintainers need to know how to denote:
  • the entire package as “deprecated” and optionally provide recommended package(s) with a short description as the alternative in file-based catalogs via the bundle-based workflow using the current Red Hat build pipeline.
  • an update channel as “deprecated” and optionally provide recommended channel(s) with a short description as the alternative in file-based catalogs via the bundle-based workflow using the current Red Hat build pipeline.
  • a specific version as “deprecated” and optionally provide recommended version(s) with a short description as the alternative in file-based catalogs via the bundle-based workflow using the current Red Hat build pipeline 

• (Pre-installation) OLM CLI users (cluster-admin or an admin-type persona) need to know how to query OLM Package Server to see:
  • i) if an operator package is deprecated entirely or is currently subscribed to a deprecated channel
  • ii) the recommended alternative to the depreciated content with a short description.

• (Post-installation) OLM CLI users (cluster-admin or an admin-type persona) need to know to use OLM Subscription API to see:
  • i) if an operator package is deprecated entirely or is currently subscribed to a deprecated channel
  • ii) the recommended alternative to the depreciated content with a short description.

• Admin-type users need to know how to generate an aggregated report with another tooling from the deprecation marker/indicator to know centrally from their cluster fleets if any operator package installed was deprecated and out of support.

• [Need Console support] OLM/OCP console users (cluster-admin or an admin type of persona) need to know if an installed operator package is deprecated entirely, is currently subscribed to a deprecated channel, or currently stays in a deprecated version.

Interoperability Considerations

• With Red Hat build pipeline for Red Hat internal operator package maintainers.
• With OLM v0 with the supported target OpenShift version.