monitoring-stack-operator
The monitoring stack operator is a Kubernetes operator which enables the management of independent and self-contained, Prometheus-based monitoring stacks through Kubernetes CRDs.
The project is based on the controller-runtime library.
Development
In order to contribute to this project, make sure you have go 1.17 on your local machine.
Commit message convention
Commit messages need to comply to the Conventional Commits specification and should be structured as follows:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
The type and description are used to generate a changelog and determine the next release version. Most commonly used types are:
-
fix:
a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning). -
feat:
a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning). -
BREAKING CHANGE:
a commit that has a footer BREAKING CHANGE:, or appends a!
after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
Other than fix:
and feat:
, the following type can also be used: build:
, chore:
, ci:
, docs:
, style:
, refactor:
, perf:
and test:
.
Manifest generation
The Kubernetes CRDs and the ClusterRole needed for their management are generated from go types in pkg/apis
.
Run make generate
to regenerate the Kubernetes manifests when changing these files.
This project uses the controller-gen for code generation. For detailed information on the available code generation markers, please refer to the controller-gen CLI page in the kubebuilder documentation
Running the operator in kind
-
Install kind
-
Create a local kubernetes cluster with
kind create cluster
. -
Apply the CRDs by running
kubectl apply -k deploy/crds/kubernetes
-
Install OLM locally by running
make $(pwd)/tmp/bin/operator-sdk ./tmp/bin/operator-sdk olm install
-
-
Apply the dependecies; i.e - Prometheus Operator and Grafana Operator by running
kubectl apply -k deploy/dependencies
-
Set the
KUBECONFIG
environment variable to your local cluster and run the operator withgo run cmd/operator/main.go
. -
Alternatively, you can also set the
kubeconfig
on the command line:go run cmd/operator/main.go --kubeconfig <path-to-kubeconfig>
TIP: Using fd
and entr
to automatically build and run operator can come handy.
E.g the following re-runs operator when any of the .go
files change.
fd .go$ -- cmd pkg |
entr -rs 'go run cmd/operator/... --zap-devel --zap-log-level=10 2>&1 |
tee ./tmp/operator.log
The above can be tweaked to automatically run make generate
when the pkg/apis/
change.
Running e2e tests
E2E tests are run against a deployment, so it requires operator to be running
in cluster or outside it (go run ./cmd/operator/...
). To run e2e tests locally,
-
Follow the section above to run the operator'
-
In a new terminal, run
go test -v ./test/e2e/...
Managing releases
This project follows SemVer 2.0.0
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Creating new releases is fully automated and does not require any human interaction. The changelog, release notes and release version are generated by the CI based on the commits added since the latest release.
Triggering new releases
In order to trigger a new release, create a new branch from the latest main and run make initiate-release
.
This will create a new commit with a message which the CI uses to initiate the release process.
The commit will contain a change to the CHANGELOG.md and VERSION inferred based on the commits added since the previous release.
Create a PR against the main
branch and merge it once it is approved. Monitor the release process and ensure that:
-
The correct tag has been created for the newly created release.
-
A pre-release is created in Github Releases for the newly created tag.
-
A new OLM bundle has been generated and added to the candidate channel.
Forcing a release version
A release version can be forced by running
make initiate-release-as RELEASE_VERSION=<version>
For example,
make initiate-release-as RELEASE_VERSION=1.4.0