Note:

This epic is a follow up to https://issues.redhat.com/browse/OTA-226 .

Goal:

As an administrator, I would like to keep the graphs from the local instance OpenShift update service (OSUS) in the disconnected environment same as public instance of OSUS run by Red Hat.

As part of the current method to deploy the OpenShift Update Service (OSUS) operator in disconnected/ restricted network environments customers need to build the graph data container image themselves [1] . We went with release of the OSUS without releasing the graph-data image because ACM needed OSUS for Verizon. However asking customers to build an image to use with OSUS operator is not an acceptable solution for long term as an software vendor we need to give everything packaged and signed to customers.

Asking customers to build an image can be error prone for human mistakes .Also it might create compliance issues as well.

The above goal can be achieved by releasing cincinnati-graph-data as a container image.

 [1] https://docs.openshift.com/container-platform/4.8/updating/installing-update-service.html#update-service-graph-data_update-service

Problem:

Customers have no mechanism to make updates known to their disconnected clusters. Today, they must manually run 'oc adm upgrade' with a pointer to the update payload residing on their local container image registry. They need a way to easily make this information available to allow for update automation and version control.

Why is this important:

Many of our customers need to host their clusters in secure and isolated environments that are disconnected from the rest of the world. This is especially true for customer that extend the boundary of their datacenter by augmenting it public cloud compute resources. They need a way to control what updates get published across all of their clusters.

Some more context:

OpenShift Update Service (OSUS) uses Cincinnati protocol. Cincinnati uses a[ directed acyclic graph (DAG) to represent the valid updates. In our case the graph contains the OpenShift versions. 

To build the graph it needs two kinds of metadata i.e. metadata from OCP release images (primary metadata) and cincinnati-graph-data[1] (secondary metadata). The graph is used by OpenShift clusters to get information on the next available update for over the air update.  

 Red Hat runs a public instance of OSUS which gets the primary metadata from OCP release images hosted in Quay.io, cincinnati-graph-data[1] from github for the secondary metadata.  

 Recently we have released OSUS operator[2] for customers who want to run a separate instance of update service. Especially in network restricted environments or disconnected environments as these environments have no internet access, hence no access to public instances of OSUS.  

 To further improve the user experience around updating a restricted network or disconnected OpenShift cluster we need to release the container image of cincinnati-graph-data [1] for the instance of OpenShift update service (OSUS) running locally in the disconnected environment.

 cincinnati-graph-data [1] gets updated a few times almost everyday as it provides a way for OCP engineering to dynamically control the graph as the primary metadata can not be changed for the OCP release. For example when we find a bug (post release) which might impact customer clusters we can block the edge to that version with the help of schema we have in cincinnati-graph-data [1]. That protects our customers from going to that version with a bug. So we need to release the image every time the repository[1] changes. Or we can at least release a few times a day to start with if we can not release per commit initially because of some reason.  

 The goal is to have automated release for cincinnati-graph-data images from CPaaS. The images need to be signed with the RH golden key as this will be used for production clusters. The image will be a scratch build and it will only contain yaml files. There will not be any runtime or binaries in the image. This will help us to release the images without any advisory or errata. Because releasing with errata will slow down the process and will be counter productive to our goal.  

 ART will copy the image from the CPaaS pipeline and push it into the quay as this will help customers to mirror the graph image along with the release images.  

[1] https://github.com/openshift/cincinnati-graph-data/

[2] https://docs.openshift.com/container-platform/4.8/updating/installing-update-service.html

--------

Superceded by OTA-832 oc-mirror should pull the graph-data YAML tarball from OSUS