---
# System prepended metadata

title: FBC Advanced Issues Workspace
tags: [fbc]

---

---
tags: fbc
title: FBC Advanced Issues Workspace
---
# FBC Advanced Issues Workspace
a whiteboard area for structuring add'l documentation  

---------------------------------------------------------------
## schema-based basic template

format of CLI is 
```mermaid
graph TD
 A(cli) -- assess args --> A
 A -- creates objects --> B(obj creation)
 B -- assess contents -->  B(fulfillment)
 ```
render results in different outputs (basic/semver return declcfg&error, but composite returns only error -- since its products are written to FS).
not worth faking, since which results would be returned?  multidoc format could mean *all* but meaningless w/o some kind of path indication since partitioned scope is all that keeps the contents from colliding.


## Converting FBC to `semver veneer`

Needs
* mvp deprecation
* preservation of non-conformant channels from origin


-------------------------------------------------------------------

## Deprecated Channels

### Deprecated Channels proposals
https://hackmd.io/xgPy6mErQ6WFoPVkLRdDfA?view


### Deprecated Channels revamped (former OLM-2087)

Background: Description of OLM-2087 (since we need to slice)
**Customer Problem**: Stay on the supported update path

Operator package maintainers are using channels as a mechanism to deliver updates for a certain base version (3.x, 4.x, 5.x) of their Operator or for certain degrees of release stability (nightly vs stable). At some point in the lifecycle of an operator the authors may want to either change their channel naming scheme or start to discontinue some of the channels they are currently maintaining without outright removing them from the catalog. Eventually maintainers want to have a way to mark certain version lines as deprecated while at the same time giving the customer information about what the supported update path looks like in a different channel. For example: "The main line in the 4.x channel is being discontinued, please switch to 5.x or newer."
OpenShift currently lacks a way to transport this information and call-to-action to the administrator, other than static documentation.
This will also serve as preparation for customers regarding eventual removal of deprecated channels in catalogs for newer OCP versions (e.g. "The 4.x channel has been deprecated since 2 OpenShift releases now, the next OpenShift release will not contain it anymore"). Deprecation markers provide visibility into future updates (or lack thereof) for customers.

**Goals:** An Operator package maintainer has the ability to mark channels as deprecated and optionally provide pointers to an update path in another channel. This allows cluster admins get notified when installed Operators are currently subscribed to a deprecated channel and they get information about in which channel they need to switch in order to stay on the supported path. This way they can see that an update path exists outside of their existing, deprecated channel without having to switch to that channel just yet. Channel deprecation markers will also allow us to discourage users from installing software from deprecated channels.

**Problem Statement:** Currently there is no way to deprecate channels other than to remove them. Removing channels, for instance from one OCP release to the next, will happen without any notice towards the cluster admin and it will leave their existing Operators orphaned without any information. Also, users lack information to which channel the Operator should be switched to be on a maintained, supported update path again other than reading documentation.

**Why is this important:** Red Hat Operators are often qualified to be supported for a certain set of OCP releases per Operator version or Application version (e.g. the Quay operator is aligned to Red Hat Quay release versions and follows a minor-versioned based naming scheme for channels). Alternatively Operator maintainers may also want to change their channel naming scheme over time. A deprecation method is required for the existing released channels to trigger different behavior in OLM and/or the OpenShift Console when using a deprecated channel (either at install time or when already installed on the cluster). In general customers should update frequently and need to understand if their update path continues beyond their current channel selection

**Assumptions:**

* Operator maintainers use one of the suggested channel naming schemes:
  * Operator minor/major versions as their channel naming scheme
  * Application minor/major versions as their channel naming scheme
  * stable/candidate/fast naming schemes
  * for an MVP it is enough to have a static pointer to the replacing channel in the metadata
 
**Dependencies:**

* FBC
  * FBC support added to redhat operator pipelines
  * OpenShift Console to support visual callouts of deprecated installed content / channels in OLM screens

**Prioritized list of required features:**

* An Operator maintainer can mark a channel as deprecated with out (re-releasing) bundles instead of deleting them
* An Operator maintainer can provide a replacement channel statically by name in the catalog metadata so that admins get a pointer to which channel and/or which Operator they should switch to, in order to stay supported (interims solution until we have OLM-2059)
* A cluster admin gets notified when installing an Operator from a deprecated channel (hence out of support)
*  A cluster admin gets notified when an installed Operator is subscribed to a deprecated channel and hence out of support 
* A cluster admin gets a suggestion to use a different channel if the Operator maintainer provided one
* A cluster admin should be discouraged from installing software from a deprecated channel, e.g. by hiding deprecated channels from the UI or requiring a manual override to force the installation from a deprecated channel
* OLM emits alert events for operators installed from a deprecated channel so that non-OpenShift users can also benefit from this information

Acceptance Criteria

* CI - MUST be running successfully with tests automated
* Release Technical Enablement - Provide necessary release enablement details and documents.
* Upstream Documentation
* Downstream Documentation
* Console Support

Open questions:

    - is a static pointer to an alternate, channel that is supposed to replace the deprecated channel enough?

Previous work:

    https://github.com/operator-framework/enhancements/pull/113/files











