Skip to content

Latest commit

 

History

History
90 lines (68 loc) · 3.91 KB

README.md

File metadata and controls

90 lines (68 loc) · 3.91 KB
Raw

kubevirt-ssp-operator

Operator that manages Scheduling, Scale and Performance addons for KubeVirt

Prerequisites

  • Golang environment and GOPATH correctly set
  • Docker (used for creating container images, etc.) with access for the current user
  • a Kubernetes 1.13 /OpenShift 4 instance
  • Operator SDK

Installation instructions

The kubevirt-ssp-operator requires a Openshift cluster to run properly. Installation on vanilla kubernetes is technically possible, but many features will not work, so this option is unsupported.

Using HCO

The Hyperconverged Cluster Operator automatically installs the SSP operator when deploying. So you can just install the HCO on your openshift cluster.

Manual installation steps

We assume you install the kubevirt-ssp-operator AFTER that kubevirt is succesfully deployed on the same cluster.

You can install the kubevirt-ssp-operator using the provided manifests.

Assuming you work from the operator source tree root:

cd kubevirt-ssp-operator

Select the namespace you want to install the operator into. If unsure, the kubevirt namespace is a safe choice:

export NAMESPACE=kubevirt

To avoid incurring in the github API throttling, if you have a github personal access token, you should set it now, by doing something like

export GITHUB_TOKEN=...

Now, run in your repo:

hack/install-operator.sh $NAMESPACE

Generate the YAML manifests

The generation process requires the operator SDK binary. If present in your path, the process will use that, otherwise it will be downloaded from the release channel. To regenerate the manifests, do in your repo:

make manifests

Find the manifests in the _out directory once done.

Manifests, CSV generator and HCO integration

The kubevirt-ssp-operator provides three way to consume its manifests

  1. individual manifests files under deploy and deploy/crds. Please note that deploy/olm-catalog is autogenerated. these are the authoritative manifests that the developers maintain and enhance, for example when they add features. An end user should not, however, consume them directly. If you want to install the kubevirt-ssp-operator without HCO, please use the hack/install-operator.sh helper.
  2. CSVs and manifests to be used with HCO. HCO is the preferred way to deploy the kubevirt-ssp-operator. We provide CSV file and package file (and everything else), autogenerated on release using make manifests. These manifests are available for download in the release page. This step creates both the unversioned CSV (see below) and the versioned -per release CSV. This is because...
  3. Recent HCO prefer to consume the CSV from the container images, using the org.kubevirt.hco.csv-generator.v1 LABEL entrypoint. The HCO build process will invoke the script on each container, expecting an up to date, dynamically generated CSV as output, and will take care of merging. In the kubevirt-ssp-operator case, this is created from the unversioned CSV generated in the step #2 above.

Functional tests

We use traviskube to integrate the functional tests on travis. Make sure you initialize the submodules. In your repo:

git submodule init

To run the functional tests, you will need access to a OKD cluster. The travis script set up from scratch a minishift environment to run the tests into.

Once the environment is set up, you can run the tests by doing, in your repo:

make functests