Source code for the controller is at https://github.com/openshift/release-controller

The release-controller automatically builds OpenShift release images when new images are created for a given OpenShift release. It detects changes to an image stream, launches a job to build and push the release payload image using oc adm release new, and then runs zero or more ProwJobs against the artifacts generated by the payload (passed as ENV vars to the ProwJob containers). If all prow jobs pass, the release is considered Accepted and any artifacts are promoted elsewhere. Any failures result in the release being marked a failure.

Supported verification steps:

1. ProwJob defined in the ci-operator/jobs/openshift/release/openshift-release-*-periodics.yaml folder
2. Future: Manual
3. Future: Webhook?

Supported publish methods:

1. Update a branch image stream tag to point to the release image stream tag.
2. Future: Mirror to DockerHub or Quay

Releases are given names as a UTC timestamp 20060504010203 based on when they were created. Data about the release is tracked as an annotation on the release image stream tag.

• In the --release-namespace:
  • An image stream with the release name that contains the snapshot of the release image stream
  • An image stream tag with the release name on the release image stream
  • An image stream tag on the release image stream as a result of a publish step that points to the release tag
• In the --job-namespace:
  • A Kubernetes Job that builds the release payload and then pushes it to <release-namespace>/release
• In the --prow-namespace:
  • One ProwJob and pod for each verification step defined on a release, for each release tag. They are prefixed with the release name.

The release-*.json files are set as annotations on ocp/4.X-art-latest and origin/4.X image streams. A secret must be created in the ci-release namespace called source with a single file config.json that is a Docker config.json carrying the secrets required to pull sources for built images. The job that creates the payload will use this image, but the secret will not be used outside of that namespace for anything other than building the payload.

To see details about an image stream tag:

$ oc get is -n openshift release -o yaml

To abort/remove a release tag:

$ oc delete istag -n openshift release:<release_name>

• deploy-*.yaml - the controller definitions
• images-*.yaml - definitions of the image streams used by the publish / build rules
• releases/release-*.json - definitions of the build and publishing rules for sets of images
• repos/ocp-*-*.repo - definitions where RPMs are loaded from for OCP builds
• rpms-*.yaml - definitions of the services that exposed mirrored RPMs within the cluster

To get RPMs into the build system, OpenShift uses base images that have an injected .repo file pointing to an in-cluster proxy that has permissions to pull from the correct OCP RPM repos for each release.

These proxies (one per core configuration) run from the ocp namespace and have the DNS names in cluster base-4-Y.ocp.svc on port 80. Each proxy performs authentication to https://mirror.openshift.com/enterprise/reposync/* to access mirrors of the content repos from Red Hat Brew. When image builds within OpenShift CI try to install RPMs, they are using these mirrors exclusively (so that no RPMs that aren't part of the official builds can be consumed).

See rpms-ocp-*.yaml for the definition of each proxy service, ocp-*.repo for each set of mirrored repos, and the root Makefile in the repo for the script that creates the Makefiles.

In general, new RPMs should be added to the correct Brew tags at Red Hat for OCP first (since we need those to eventually build). Those are mirrored nightly by the SRE team to https://mirror.openshift.com/enterprise/reposync/4.Y. If a set of RPMs need to be added (a separate brew tag) that is compatible with the existing RPM sets, then we would add it to the appropriate ocp-4.Y-default.repo (which all images can use). If the repo is incompatible with any of the RPMs in the default repos (like the OpenStack project), a new type of ocp-4.Y-NAME.repo has to be created (similar to ocp-4.2-openstack.repo) that points to the correct mirrors. Then the images that want to use that as a base have to inject the correct RPM repo (TODO: future changes will mount these automatically) and then depend on that base. For an example, see the kuryr ci-operator definitions.

See the OWNERS file in this directory for approvers.