Member Operator

This is the CodeReady Toolchain Member Operator repository. It contains the OpenShift Operator that is deployed on the "member" cluster in the SaaS.

Build

Requires Go version 1.13 - download for your development environment here.

This repository uses Go modules. You may need to export GO111MODULE=on to turn modules support "on".

Development

To run this operator locally you need to have at least one Minishift profile started:

$ minishift start --profile member

Then you can run the operator locally with the help of operator-sdk (you need version v0.10.0 or higher):

$ make up-local

That Makefile target takes care of additional several steps which can be executed separately:

• logging as system:admin user: $ make login-as-admin

• creating local test namespace: $ make create-namespace

• deploy CRDs: $ make deploy-crd

• building the project: $ make build

• deploying ClusterRole/ClusterRoleBinding and creating ServiceAccount: $ make deploy-rbac

There are a few more targets that you can find useful:

• to login as system:admin user and enter the local test namespace: $ make use-namespace

• to remove the local test namespace: $ make clean-namespace

• to remove & create the local test namespace, and create ClusterRole/ClusterRoleBinding and ServiceAccount inside of the namespace: $ make reset-namespace

Installing operator

To install the member operator via OperatorHub you need to have OpenShift 4.2+ running and access to a docker registry. Since the operator is no available in OperatorHub nor in any registry by default, you need to deploy the image to the docker registry, create CatalogSource and ClusterServiceVersion in the openshift-marketplace namespace and then create OperatorGroup and Subscription in the namespace you want to install the operator to. Before running any make target, make sure that you have QUAY_NAMESPACE variable set to your quay username (or set to any namespace you want to push the image to).

$ export QUAY_NAMESPACE=<quay-username>

Prerequisites:

• Make sure the target OpenShift 4.2+ cluster is accessible via oc command.

• Log in to the target OpenShift cluster with cluster admin privileges

• Set the QUAY_NAMESPACE variable properly - see above

• Login to quay.io via docker login quay.io (in case you want to use quay as the docker registry)

Then, to install the operator run:

$ make install-operator

Note	The first push to quay will create member-operator repository that is private by default, so go to https://quay.io/repository/<your-username>/member-operator?tab=settings and set the repository visibility to public

That Makefile target takes care of several steps that can be executed separately:

• build the image: $ make docker-image

• push the image to registry: $ make docker-push

• create CatalogSource and ConfigMap with ClusterServiceVersion and all CRDs in the openshift-marketplace: $ make deploy-csv

• and as the last step the actual installation via creating OperatorGroup and Subscription in the test namespace.

OpenShift internal docker registry

In case you want to use the OpenShift internal docker registry instead of quay, you can achieve the same thing via running:

$ make install-operator-using-os-registry

In case you have issues with the certificate while logging/pushing to the OpenShift internal docker registry, please follow these instructions:

TO_REGISTRY=$(oc get images.config.openshift.io/cluster  -o jsonpath={.status.externalRegistryHostnames[0]})
oc get secret router-certs-default -n openshift-ingress -o json |jq -r '.data["tls.crt"]' | base64 -d >ca.crt
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/${TO_REGISTRY}.crt
sudo update-ca-trust enable
sudo systemctl daemon-reload
sudo systemctl restart docker
docker login -u kubeadmin -p $(oc whoami -t) ${TO_REGISTRY}

End-to-End tests

Background & pairing

E2E tests are not located in this repository - all e2e tests are in the toolchain-e2e repo, however, it’s still possible to run them locally from this repo - see Running End-to-End Tests.

When there is a change introduced in this repository that should be either covered by e2e tests or requires changes in the already existing tests, then all needed changes should go into the toolchain-e2e repo. The logic that executes tests in openshift-ci automatically tries to pair any PR opened for this (member-operator) repository with a branch that potentially exists in the developer’s fork of the toolchain-e2e repo. This pairing is based on the current branch name.

For example, if a developer with a GH account cooljohn opens a PR (for member-operator repo) from a branch fix-reconcile, then the logic checks if there is a branch named fix-reconcile also in the cooljohn/toolchain-e2e fork. If there is a match, then the logic:

1. clones the latest changes from codeready-toolchain/toolchain-e2e

2. fetches the fix-reconcile branch from cooljohn/toolchain-e2e fork

3. merges the master branch with the changes from fix-reconcile branch

4. clones the latest changes from host-operator repo, then builds and deploys the host-operator image out of it

5. builds & deploys the member-operator image from the code that is in the PR

6. runs the e2e tests against both operators from the merged branch of the toolchain-e2e repo

If the branch with the same name does not exist, then it only clones the latest changes from toolchain-e2e and runs e2e tests from the master.

If you still don’t know what to do with e2e tests in some use-cases, go to What to do section where all use-cases are covered.

Prerequisites if running locally

Minishift

If you are running this tests locally on minishift, make sure that you have exposed minishift’s docker-env, so that deployment can use locally built image. You can expose it by running following command. eval $(minishift docker-env)

Note	This is not required for openshift-ci environment

OpenShift 4.2+

• Make sure you have set the QUAY_NAMESPACE variable: export QUAY_NAMESPACE=<quay-username>

• Log in to the target OpenShift cluster with cluster admin privileges

• The visibility of member-operator repository in quay is set to public (https://quay.io/repository/<your-username>/member-operator?tab=settings)

Running End-to-End Tests

Although the e2e tests are in the separated repository, it’s still possible to run them from this repo (member-operator) and also against the current code that is the local repository (directory). There are two Makefile targets that will execute the e2e tests:

• make test-e2e - this target clones latest changes from toolchain-e2e and runs e2e tests for both operators from the master. As deployment for member-operator it uses the current code that is in the local repository.

• make test-e2e-local - this target doesn’t clone anything, but it runs run e2e tests for both operators from the directory ../toolchain-e2e. As deployment for member-operator it uses the current code that is in the local repository.

The tests executed within toolchain-e2e repo will take care of creating all needed namespaces with random names (or see below for enforcing some specific namespace names). It will also create all required CRDs, role and role bindings for the service accounts, build the Docker images for both operators and push them to the OpenShift container registry. Finally, it will deploy the operators and run the tests using the operator-sdk.

NOTE: you can override the default namespace names where the end-to-end tests are going to be executed - eg.: `make test-e2e HOST_NS=my-host MEMBER_NS=my-member` file.

What to do

If you are still confused by the e2e location, execution and branch pairing, see the following cases and needed steps:

• Working locally:

  • Need to test your code using the latest version of e2e tests from toolchain-e2e repo:

    • execute make test-e2e

  • Need to test your code using e2e tests located in ../toolchain-e2e repo:

    • execute make test-e2e-local

• Creating a PR:

  • Your PR doesn’t need any changes in toolchain-e2e repo:

    • check the name of a branch you are going to create a PR for

    • make sure that your fork of toolchain-e2e repo doesn’t contain branch with the same name

    • create a PR

  • Your PR requires changes in toolchain-e2e repo:

    • check the name of a branch you are going to create a PR for

    • create a branch with the same name within your fork of toolchain-e2e repo and put all necessary changes there

    • push all changes into both forks of the repositories toolchain-e2e and member-operator

    • create a PR for member-operator

    • create a PR for toolchain-e2e

Verifying the OpenShift CI configuration

It’s possible to verify the OpenShift CI config from the developer’s laptop while all the jobs are executed on the remote, online CI platform:

1. checkout and build the CI Operator command line tool

2. login to https://console.svc.ci.openshift.org (via GH OAuth) and copy the login command (you may need to switch to the application console)

3. login with the command aferementioned

4. run the CI jobs with

   ci-operator --config ../../openshift/release/ci-operator/config/codeready-toolchain/member-operator/codeready-toolchain-member-operator-master.yaml --git-ref=codeready-toolchain/member-operator@master

   assuming that the OpenShift Release repo was checked you.

Note	you can ignore the RBAC issues that are displayed in the console

Note	prepare some 🍿or ☕️, the whole build can take more than 10 minutes…​

Adding clusters to SaaS

The CodeReady Toolchain architecture contains two types of clusters host and member. To connect these two clusters together it is necessary to run a script add-cluster.sh that is part of the toolchain-common repository. For more detailed information about the script see the README "Script add-cluster.sh" chapter.

There are two Makefile targets available in this repository that execute the script:

• $ make add-member-to-host that executes ../toolchain-common/scripts/add-cluster.sh member member-cluster

• $ make add-host-to-member that executes ../toolchain-common/scripts/add-cluster.sh host host-cluster

Note	In order to run them, you need to have the toolchain-common repository cloned to the same parent directory as this repository exists in.