Openshift Knative Eventing

This repository holds Openshift's fork of knative/eventing with additions and fixes needed only for the OpenShift side of things.

Release Schedule

A little table to coordinate the midstream release/ci automation for our fork repo.

Possible Outdate Periodics

When adding a new release, check if the corresponding version in "Possible Outdated Periodics" column is no longer supported in OpenShift Serverless - Support Dates Matrix and remove the corresponding periodics in such case.

Release	Release Manager	Possible Outdated Periodics
v0.25	devguyio	OSS 1.15 (v0.21 periodics)
v0.26	lberk	OSS 1.16 (v0.22 periodics)
v1.0	aliok	OSS 1.17 (v0.23 periodics)
v1.1	matzew	OSS 1.18 (v0.24 periodics)
v1.2	pierdipi	OSS 1.19 (v0.25 periodics)
v1.3	devguyio	OSS 1.20 (v0.26 periodics)
v1.4	lberk	OSS 1.21 (v1.0 periodics)
v1.5	aliok	OSS 1.22 (v1.1 periodics)
v1.6	matzew	OSS 1.23 (v1.2 periodics)
v1.7	pierdipi	OSS 1.24 (v1.3 periodics)

CI Rotation

Week Starting	CI Duty
2022-10-17T01:00:00Z	lberk
2022-10-24T01:00:00Z	matzew
2022-10-31T01:00:00Z	pierDipi
2022-11-07T01:00:00Z	aliok
2022-11-14T01:00:00Z	lberk
2022-11-21T01:00:00Z	matzew
2022-11-28T01:00:00Z	pierDipi
2022-12-05T01:00:00Z	matzew
2022-12-12T01:00:00Z	creydr
2022-12-19T01:00:00Z	lberk
2022-12-26T01:00:00Z	aliok

How this repository works ?

The main branch holds up-to-date specific openshift files that are necessary for CI setups and maintaining it. This includes:

• Scripts to create a new release branch from upstream
• CI setup files
  • operator configuration (for Openshift's CI setup)
  • tests scripts
• Operator's base configurations

Each release branch holds the upstream code for that release and our openshift's specific files.

CI Setup

For the CI setup, two repositories are of importance:

• This repository
• openshift/release which contains the configuration of CI jobs that are run on this repository
• openshift-knative/hack which contains the configuration to generate CI jobs for openshift/release.

Create a new release

Deliverables:

• Tagged images on quay.io
• An OLM manifest referencing these images
• Install documentation

High-level steps for a release

Building upstream

The release README provides more detail for steps 1. and 2. below.

1. Create a release branch from the upstream’s release tag, i.e. release-v0.5.0. This is created in the fork that we maintain of upstream.
2. Create a CI job for that branch in openshift/release. See our CI setup instructions for deeper information but don't forget to update the cron expression in generate-ci-config.sh for the branch.
3. Do whatever you need to do to make this CI pass
4. Create a “dummy” PR with a ci file, which contains the current output of “date”. This is to trigger CI explicitly.
5. Make sure that PR is green and merge it. This will trigger the images to become available on the CI registry.

Mirroring images to quay.io

1. Make sure the images for the release are built and “promoted”. This can be verified by “docker pull”ing them, for example: “docker pull registry.svc.ci.openshift.org/openshift/knative-v0.5.0:knative-eventing-controller”
2. If that’s the case, create/amend an image mirroring mapping file as described here.

Update the operator

1. Copy the upstream release manifest to the operator’s deploy/resources directory. All files in this directory will be applied, so remove any old ones.
2. Update the manifest[s] to replace gcr.io images with quay.io images.
3. Build/test the operator
4. Commit the source
5. export VERSION="vX.Y.Z" # replace X.Y.Z as appropriate 6.. operator-sdk build --docker-build-args "--build-arg version=$VERSION" quay.io/openshift-knative/$OPERATOR_NAME:$VERSION
6. docker push quay.io/openshift-knative/$OPERATOR_NAME:$VERSION
7. git tag $VERSION; git push --tags

Update OLM metadata

1. The following instructions amount to mirroring upstream changes in the OLM manifests beneath openshift/olm in our forks.
2. Create a new *.clusterserviceversion.yaml for the upstream release. It’s easiest to copy the previous release’s CSV to a new file and update the name, version, and replaces fields, as well as the version of the operator’s image.
3. Ensure the upstream release’s RBAC policies match what’s in the CSV. Any upstream edits should be carried over.
4. Mirror any upstream manifest changes to CRD’s in the corresponding *.crd.yaml file.
5. Update the currentCSV field in the *.package.yaml file.
6. Regenerate the *.catalogsource.yaml file using the catalog.sh script. For example,

DIR=openshift/olm \
~/src/knative-operators/etc/scripts/catalog.sh \
> openshift/olm/knative-serving.catalogsource.yaml

Tag the repository

Get a "LGTM" from QE

Get a "LGTM" from Docs

Gather release notes from JIRA/GitHub

Send a release announcement