Skip to content
KUDO Cassandra Operator
Go Shell Dockerfile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.

KUDO Cassandra Operator



Cloning the git repository

git clone --recurse-submodules /path/to/kudo-cassandra-operator

All commands assume that you're in the project root directory.

cd /path/to/kudo-cassandra-operator

Choosing a name and a namespace for the instance


Creating the namespace (if it doesn't exist)

kubectl create namespace "${kudo_cassandra_instance_namespace}"

Installing the KUDO Cassandra operator

kubectl kudo install ./operator \
        --instance="${kudo_cassandra_instance_name}" \

Checking out the deploy plan

kubectl kudo plan status \
        --instance="${kudo_cassandra_instance_name}" \

Checking out the pods

kubectl get pods -n "${kudo_cassandra_instance_namespace}"

Getting the 0th pod name

kudo_cassandra_pod_0="$(kubectl get pods \
                                -o 'jsonpath={.items[0]}' \
                                -n "${kudo_cassandra_instance_namespace}")"

Checking out the output of nodetool stats

kubectl exec "${kudo_cassandra_pod_0}" \
        -n "${kudo_cassandra_instance_namespace}" \
        -- \
        bash -c 'nodetool status'

Running a cassandra-stress workload

kubectl exec "${kudo_cassandra_pod_0}" \
        -n "${kudo_cassandra_instance_namespace}" \
        -- \
        bash -c "cassandra-stress write -node ${svc_endpoint}"

Uninstalling the KUDO Cassandra operator

./scripts/ \
  --instance "${kudo_cassandra_instance_name}" \
  --namespace "${kudo_cassandra_instance_namespace}"


Additional requirements

Compiling templates


Running static code analyzers

Automatically formatting all files


Checking if all files pass formatting and linting checks


Building Docker images


Running tests

Style guide

Opening pull requests

PR titles should be in imperative mood, useful and concise. Example:

Add support for new thing.

PR descriptions should include additional context regarding what is achieved with the PR, why is it needed, rationale regarding decisions that were made, possibly with pointers to actual commits.


To make it possible for the new thing we had to:
- Prepare this other thing (5417f75)
- Clean up something else (ec4c78d)

This was required because of this and that.

Example output of thing:

      "a": 2

Please look into
for more context.

Merging pull requests

When all checks are green, a PR should be merged as a squash-commit, with its message being the PR title followed by the PR number. Example:

Add support for new thing. (#42)

The description for the squash-commit will ideally be the PR description verbatim. If the PR description was empty (it probably shouldn't have been!) the squash-commit description will by default be a list of all the commits in the PR's branch. That list should be cleaned up to only contain useful entries (no fix, formatting, changed foo, refactored bar), or rewritten so that additional context is added to the commit, like in the example above for PR descriptions.

You can’t perform that action at this time.