Goal:

Update the upstream_sources.yaml to match the decided references and have all components (images) built properly as a baseline for the development cycle.

Requirements:

1. Initial branch structure should be ready for the current release
2. OSC Releases: Dependencies and refs must have the right references for the current release

Before starting this task, double-check our "OSC Releases: Dependencies and refs" to see what reference was decided for the current release.There you can also find which components are using which repositories. This document should be our source of truth.

Let's categorize our components into two groups:

1. Components utilizing Rust code that need local vendors (Cachito cannot handle these dependencies)

• osc/midstream/kata-containers-cc
• osc/midstream/guest-components

2. Components not using Rust code (Cachito can manage these dependencies).

• openshift/sandboxed-containers-operators
• kata-containers/kata-containers
• midstream/cloud-api-adaptor

First Group: the "ugliest" (most challenging) ones

First step is to update the -vendors repositories.

Currently we have two vendors repositories:

• https://gitlab.cee.redhat.com/osc/midstream/kata-containers-vendors
• https://gitlab.cee.redhat.com/osc/midstream/attestation-agent-vendors

They are the vendors for osc/midstream/kata-containers-cc and osc/midstream/guest-components respectively, both used by the podvm-payload image.

You should compile the vendors locally and send a MR to the -vendors repositories. Run `make vendors` followed by `make sync`.

• Note: Pay attention to the output generated by the first command. You need to manually copy it to the '.cargo/config` file. Follow the instructions found at the README.md.

FUTURE IMPROVEMENT: Now we are watching the repositories at the midstream namespace with full control, allowing us to attempt merging the vendor folders into their corresponding midstream repository again. Previously, we were watching upstream, and also encountered CPaaS timeouts due to the ci_junkyard's size. If successful, this would decrease the complexity and the repository count to just two. Another option is to convince upstream to carry the rust vendors.

The steps above will make CPaaS to automatically update "-vendors" sections present at the upstream_sources.yaml file. An automatic MR will be created at the cpaas-midstream/osc-operator repository. Hold that MR open and do not accept it yet.

Now that the vendors are in place, lets test them with the right code base for osc/midstream-kata-containers-cc and osc/midstream/cloud-api-adaptor:

Make sure each section for those repositories under the upstream_sources.yaml are pointing to the right references (as defined in our document mentioned before)

• If they are right (both branch and commit), you just have to accept the CPaaS MR, generated by the previous step.
• If they are not, you need to send a new MR with both changes: The new references for the osc/midstream-kata-containers-cc and osc/midstream/cloud-api-adaptor as well the -vendors hashes of the previous MR.

This will trigger the build of our images based on the updated -vendors reference. Watch the logs in that MR to see if everything is passing.

Second Group: Components not using Rust code

Those are the easiest ones, and have a similar approach as before, the difference is that they don't have vendors, because Cachito is handling that:

For each remaining section, under the upstream_sources.yaml, verify if each component is matching the right branch/commit (as defined at our document mentioned above). If not, send a MR to this repository.

Pay attention to the target branch name. Branch name should match the upcoming release. I.e: osc-1.6-rhel-9 if we are preparing for the 1.6 release.

Make sure the distgit/containers/osc-operator/Dockerfile.in is matching what we need. Usually we need to ensure we are using the right container base image and that the steps used to build this image are matching upstream as close as possible.

General Notes:

1. Regarding the MRs, pay attention to the target branch name. Branch name should match the upcoming release. I.e: osc-1.6-rhel-9 if we are preparing for the 1.6 release.
2. Make sure the distgit/containers/*/Dockerfile.in are matching what we need. Usually we need to ensure we are using the right container base image and that the steps used to build this image are matching upstream as close as possible.
3. Dockerfile.in and upstream_sources are related and need to be in sync. For instance, sometimes upstream changes the structure, and if we are using a new version with this new structure, the dockerfile should be able to use the right paths to build the image.
4. Remember that our build system is offline so we are building in "offline mode" with the Cachito help.

Some relevant documentation:

• https://cpaas.pages.redhat.com/documentation/users/midstream/usrc_updater.html#_cachito
• https://osbs.readthedocs.io/en/latest/admins.html#cachito-integration
• https://docs.google.com/document/d/1pAPyL_ykqWg51f6DLFIGlDoufeQPdbSvC1erTy8ZlhI/edit?usp=sharing