unkin-agent
9da206dc7c
PVCs and CloudNativePG Clusters need S3 buckets and backup schedules
provisioned consistently. This operator watches the
backups.unkin.net/{schedule,destination} annotations on those objects and
provisions everything needed to back them up, with no new CRDs.
- Add a PVC controller that provisions cephrgw ObjectStoreUser/Bucket/BucketAccess,
auto-generates a restic repo-password Secret and creates a k8up Schedule scoped
to the PVC via spec.backup.volumes[].persistentVolumeClaim.claimName.
- Add a CNPG Cluster controller that provisions the same bucket stack, idempotently
patches spec.backup.barmanObjectStore (leaving a user-set destinationPath alone
with a Warning event) and creates a ScheduledBackup.
- Resolve destinations through a ConfigMap lookup table; requeue until the
BucketAccess is Ready before creating schedule resources; own-reference created
resources and retain bucket data by default.
- Add schedule-mapping helpers (k8up 5-field/shortcut pass-through, CNPG 6-field
seconds-first) and deterministic, length-bounded name derivation.
- Add unit tests (schedule mapping, name derivation, destination resolution) and
envtest controller tests for both paths, wiring the external CRDs into envtest.
- Add kubebuilder-generated RBAC, a Dockerfile (distroless/nonroot), Woodpecker
lint/test/build pipelines and a tag-triggered image push to the artifactapi
docker-internal registry, plus a version-bump Makefile and deploy manifests.
41 lines
1.7 KiB
Markdown
41 lines
1.7 KiB
Markdown
# Versioning and Branching in controller-runtime
|
|
|
|
We follow the [common KubeBuilder versioning guidelines][guidelines], and
|
|
use the corresponding tooling.
|
|
|
|
For the purposes of the aforementioned guidelines, controller-runtime
|
|
counts as a "library project", but otherwise follows the guidelines
|
|
exactly.
|
|
|
|
We stick to a major version of zero and create a minor version for
|
|
each Kubernetes minor version and we allow breaking changes in our
|
|
minor versions. We create patch releases as needed and don't allow
|
|
breaking changes in them.
|
|
|
|
Publishing a non-zero major version is pointless for us, as the k8s.io/*
|
|
libraries we heavily depend on do breaking changes but use the same
|
|
versioning scheme as described above. Consequently, a project can only
|
|
ever depend on one controller-runtime version.
|
|
|
|
[guidelines]: https://sigs.k8s.io/kubebuilder-release-tools/VERSIONING.md
|
|
|
|
## Compatibility and Release Support
|
|
|
|
For release branches, we generally tend to support backporting one (1)
|
|
major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back
|
|
further if the need arises and is very pressing (e.g. security updates).
|
|
|
|
### Dependency Support
|
|
|
|
Note the [guidelines on dependency versions][dep-versions]. Particularly:
|
|
|
|
- We **DO** guarantee Kubernetes REST API compatibility -- if a given
|
|
version of controller-runtime stops working with what should be
|
|
a supported version of Kubernetes, this is almost certainly a bug.
|
|
|
|
- We **DO NOT** guarantee any particular compatibility matrix between
|
|
kubernetes library dependencies (client-go, apimachinery, etc); Such
|
|
compatibility is infeasible due to the way those libraries are versioned.
|
|
|
|
[dep-versions]: https://sigs.k8s.io/kubebuilder-release-tools/VERSIONING.md#kubernetes-version-compatibility
|