Over the last couple of months, we've been busy building a new OKD release on CentOS Stream CoreOS (SCOS), and were able to present it for the OpenShift Commons Detroit 2022. While some of us created a Tekton pipeline that could build SCOS on a Kind cluster, others were tediously building the OKD payload with Prow, but also creating a Tekton pipeline for building that payload on any OpenShift or OKD cluster. The goal of this effort is to enable and facilitate community collaboration and contributions, giving anybody the ability to do their own payload builds and run tests themselves. This process has been difficult because OpenShift's Prow CI instance is not open to the public, and changes could thus not easily be tested before PR submission. Even after opening a PR, a non-Red Hatter will require a Red Hat engineer to add the /ok-to-test label in order to start Prow testing. With the new Tekton pipelines, we are now providing a straight forward way for anybody to build and test their own changes first (or even create their own Stream entirely), and then present the results to the OKD Working Group, which will then expedite the review process on the PR.

What is enclave support? Enclave: The purpose of a network enclave is to limit internal access to a portion of a network. A major difference between a DMZ or demilitarized zone and a network enclave is a DMZ allows inbound and outbound traffic access, where firewall boundaries are traversed. In an enclave, firewall boundaries are not traversed. oc-mirror already focuses on mirroring content to disconnected environments for installing and upgrading OCP clusters. This specific feature addresses use cases where mirroring is needed for several enclaves (disconnected environments), that are secured behind at least one intermediate disconnected network. In this context, enclave users are interested in: being able to mirror content for several enclaves, and centralizing it in a single internal registry. Some customers are interested in running security checks on the mirrored content, vetting it before allowing mirroring to downstream enclaves.

Blissful past... A couple of years ago, I would never have thought that I would get that interested in the underlying structure of containers, not to mention going into the journey of building one in Golang. I was living the blissful life of an engineer who simply uses podman pull or docker push, creates ContainerFile or Dockerfile, then runs command lines to build images from such files... sitting back and watching the standard output list the layers being built, then pushed one by one with nice digests to the registry of my choosing, under the tag of my choosing. All changed when... All this changed when I started contributing to oc-mirror, around a year ago. oc-mirror is a plugin of OpenShift's CLI, and targets disconnected clusters. It mirrors all images needed by such clusters in order to install and upgrade OpenShift as well as all its Day-2 operators from operator catalogs. Suddenly, the underground world of containers unraveled. Most of the logic of oc-mirror is about extracting metadata from images such as release images and operator catalog images, interpreting the contents of these images in order to determine the list of images that constitute a release or an operator, and later copy those images to an archive or to a partially disconnected registry.

Prerequisites At least 32G of RAM libvirt virt-install virtmanager I was using Fedora 39 Figure our the Rendez vous IP Run the following:

Matrix API Matrix provides several APIs, Client-Server API is one of them. In order to be able to send messages to a matrix room, the Tekton pipeline needs to send an access_token along with the request to the Matrix server. Thus, a prerequisite to this task is to register a Matrix user with one of the Matrix servers. Obtaining a Matrix access_token Once the registration process is done, I obtained the access_token through a simple login API call:

Here's the recipe I followed to make a simple POC of how to send notifications from the Tekton pipeline (on kind in my case) to Slack (my own slack workspace here) Creating a Slack App I simply followed Slack docs on getting a new token. It turns out that right now, you need a slack App to obtain a token. You can no longer create user tokens, now called legacy test tokens. But things turned out rather easy: On the page mentioned above, I followed Create a pre-configured app link Next, I followed the instructions