Skip to content

Latest commit

 

History

History
118 lines (88 loc) · 4.37 KB

installation.md

File metadata and controls

118 lines (88 loc) · 4.37 KB
Raw

Installation

This guide uses minikube version v1.5.2+ as the local Kubernetes cluster and quay.io for the public registry. We also test on crc version v1.7.0+. kubectl is used but can be substituted with oc.

Supported versions

Note:

  • Experimental tag refers to some workloads that might be functioning
  • To use versions of Openshift and kubernetes prior to 4.3 and 1.16.2 respectively, please use version 0.0.2 of ripsaw

Requirements

The main requirements are as follows:

Note: Please login as admin user

The following requirements are needed to make/test changes to operator:

Note: You also require a quay account to push images

The following optional requirements are needed if using OKD/OCP < 4.0:

The workloads could also have their own requirements which would be specified in the installation guide.

Deploying operator

Note: The benchmark-operator's code-name is ripsaw, so the names have been used interchangeably.

Note: If you're on a vanilla k8s distribution, then you can also deploy Ripsaw through operatorhub.io, please check ripsaw in operatorhub for more details.

First we'll need to clone the operator:

# git clone https://github.com/cloud-bulldozer/ripsaw
# cd ripsaw
# export KUBECONFIG=<your_kube_config> # if not already done

We try to maintain all resources created/required by ripsaw in the namespace my-ripsaw, as this would be the namespace, ripsaw would be installed into if deployed through operatorhub.io.

Note: But in case you've a specific usecase where you want the resources to be in a different namespace, you'll just need to edit the namespace in deploy/ as well as the operator definition.

But for sake of the documentation, let's proceed with the namespace my-ripsaw

so we'll create the namespace as follows

# kubectl apply -f resources/namespace.yaml

or if you're used to oc it'd be oc new-project my-ripsaw and oc project my-ripsaw

We'll now apply the permissions and operator definitions.

# kubectl apply -f deploy
# kubectl apply -f resources/crds/ripsaw_v1alpha1_ripsaw_crd.yaml
# kubectl apply -f resources/operator.yaml

Running workload

Now that we've deployed our operator, follow workload specific instructions to run workloads:

If you want to add a new workload please follow these instructions to submit a PR

Clean up

Now that we're running workloads we can cleanup by running following commands

# kubectl delete -f <your_cr_file>
# kubectl delete -f resources/crds/ripsaw_v1alpha1_ripsaw_crd.yaml
# kubectl delete -f resources/operator.yaml
# kubectl delete -f deploy

running CI

If you want to run CI on your laptop as part of developing a PR, you may want to use your own image location and account (i.e. your own image repository account). To do this, set 2 environment variables:

  • RIPSAW_CI_IMAGE_LOCATION - host where image repository lives (default is quay.io)
  • RIPSAW_CI_IMAGE_ACCOUNT - user account (default is rht_perf_ci).

This allows you to have the CI run on your own private image built with your PR. This assumes that your benchmark's CI script in tests/ utilizes the common code in tests/common.sh to launch ripsaw.

You can modify your ripsaw image to use a test version of your benchmark image as well. For examples, see workload.yml.j2 files in the roles/ tree and look for the image: tag.