This is a Kubernetes operator to manage Infinispan clusters.
- go 1.20 or higher.
- Docker | Podman
- Operator SDK 1.24.1
- 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
./scripts/ci/kind-with-olm.sh
and install cert-manager on it:
make deploy-cert-manager
Build the Operator image and deploy to a cluster:
skaffold dev
The dev
command will make the process follow the logs produced by the remote process.
Exiting from the process, the image will be undeployed from the cluster.
See more on Skaffold Documentation.
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 run
command returns immediately after the deploy.
The image won't be undeployed from the cluster.
See more on Skaffold Documentation.
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 Operand references:
SERVER_TAGS
inJenkinsfile
andscripts/ci/kind.sh
to include the image tage all supported OperandsINFINISPAN_OPERAND_VERSIONS
json inconfig/manager/manager.yaml
includes the latest Infinispan Server releases. Do not use the floating tags for an Operand image, e.g.13.0
.server_image_version
indocumentation/asciidoc/topics/attributes/community-attributes.adoc
to point to the latest Operand versiontest/e2e/utils/common.go
VersionManager JSON to include the latest Operanddocumentation/asciidoc/topics/ref_supported_versions.adoc
to include all supported Operandsdocumentation/asciidoc/topics/community-attributes.adoc
to use the latest supported Operand
- Commit changes with appropriate commit message, e.g "Releasing Operator <x.y.z>.Final"
- Tag the release
git tag <x.y.z>
and push to GitHub - Create and push the multi-arch image using the created tag via the "Image Release" GitHub Action
- Remove the old bundle from local
rm -rf bundle
- Create OLM bundle
make bundle VERSION=<x.y.z> CHANNELS=2.3.x DEFAULT_CHANNEL=2.3.x IMG=quay.io/infinispan/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
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
In order to test on ARM machines locally, it's necessary for a few changes to be made.
scripts/ci/kind.sh
needs to be executed with the following env variables:
DOCKER_REGISTRY_IMAGE="registry:2"
KINDEST_IMAGE="kindest/node"
KINDEST_NODE_VERSION="v1.28.7" # Must be >= 1.28.x to ensure ARM support works as expected
- When executing
make infinispan-test
, setTEST_NGINX_IMAGE="nginx"
so a multi-arch nginx container is used.
TODO