This is a Kubernetes operator to manage Infinispan clusters.
- go 1.17 or higher.
- Docker | Podman
- Operator SDK 1.3.2
- A running Kubernetes cluster
For details on how to use the operator, please read the official operator documentation.
You’ll need a Kubernetes cluster to run against. You can use KIND to get a local cluster for testing, or run against a remote cluster.
Note: Your controller will automatically use the current context in your kubeconfig file (i.e. whatever cluster kubectl cluster-info
shows).
We utilise Skaffold to drive CI/CD, so you will need to download the latest binary in order to follow the steps below:
Create a local kind cluster backed by a local docker repository, with OLM and cert-manager installed:
./hack/kind.sh`
Build the Operator image and deploy to a cluster:
skaffold dev
Changes to the local **/*.go
files will result in the image being rebuilt and the Operator deployment updated.
Build the Operator image with dlv so that a remote debugger can be attached to the Operator deployment from your IDE.
skaffold debug
Build the Operator image and deploy to a cluster:
skaffold run
The skaffold dev|debug|run
commands can all be used on a remote k8s instance, as long as the built images are accessible
on the cluster. To build and push the operator images to a remote repository, add the --default-repo
option, for example:
skaffold run --default-repo <remote_repo>
The OLM bundle manifests are created by executing make bundle VERSION=<latest-version>
.
This will create a bundle/
dir in your local repository containing the bundle metadata and manifests, as well as a
bundle.Dockerfile
for generating the image.
The bundle image can be created and pushed to a repository with:
make bundle-build bundle-push VERSION=<latest-version> IMG=<operator-image> BUNDLE_IMG=<bundle-image>
To create an Operator release perform the following:
- Update the
RELATED_IMAGE_OPENJDK
field inconfig/manager/manager.yaml
to point to the latest .Final tag of Infinispan Server image. Do not use the floating tags for a stream, e.g.13.0
. - Commit changes with appropriate commit message, e.g "Releasing Operator <x.y.z>.Final"
- Tag the release
git tag <x.y.z>
- Create and push the image
make operator-build operator-push VERSION=<x.y.z>.Final IMG=quay.io/infinispan/operator:<x.y.z>.Final
- Remove the old bundle from local
rm -rf bundle
- Create OLM bundle
make bundle VERSION=<x.y.z> CHANNELS=2.2.x DEFAULT_CHANNEL=2.2.x IMG=quay.io/remerson/operator:<x.y.z>.Final
- Copy contents of
bundle/
and issue PRs to: - Once PR in 5 has been merged and Operator has been released to OperatorHub, update the "replaces" field in
config/manifests/bases/infinispan-operator.clusterserviceversion.yaml
toreplaces: infinispan-operator.v<x.y.z>
- Update the
RELATED_IMAGE_OPENJDK
field inconfig/manager/manager.yaml
to use the required floating tag, e.g.13.0
- Update
scripts/ci/install-catalog-source.sh
VERSION
field to the next release version - Update
scripts/create-olm-catalog.sh
to include the just released version inBUNDLE_IMGS
and the next release version in the update graph - Commit changes with appropriate commit message, e.g "Next Version <x.y.z>"
make test
The different categories of integration tests can be executed with the following commands:
make infinispan-test
make cache-test
make batch-test
make multinamespace-test
make backuprestore-test
The target cluster should be specified by exporting or explicitly providing KUBECONFIG
, e.g. make infinispan-test KUBECONFIG=/path/to/admin.kubeconfig
.
The following variables can be exported or provided as part of the make *test
call.
Variable | Purpose |
---|---|
TEST_NAME |
Specify a single test to run |
TESTING_NAMESPACE |
Specify the namespace/project for running test |
RUN_LOCAL_OPERATOR |
Specify whether run operator locally or use the predefined installation |
EXPOSE_SERVICE_TYPE |
Specify expose service type. NodePort | LoadBalancer | Route . |
PARALLEL_COUNT |
Specify parallel test running count. Default is one, i.e. no parallel tests enabled. |
Cross-Site tests require you to create two k8s Kind clusters or utilize already prepared OKD clusters:
$ source scripts/ci/configure-xsite.sh $KIND_VERSION $METALLB_VERSION
Actual $KIND_VERSION
and $METALLB_VERSION
values can be explored inside the Jenkinsfile
file
To test locally in running Kind clusters, run:
$ go test -v ./test/e2e/xsite/ -timeout 30m
TODO