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.
20 lines
689 B
Markdown
20 lines
689 B
Markdown
# Contributing guidelines
|
|
|
|
## Sign the CLA
|
|
|
|
Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests.
|
|
|
|
Please see https://git.k8s.io/community/CLA.md for more info
|
|
|
|
## Contributing steps
|
|
|
|
1. Submit an issue describing your proposed change to the repo in question.
|
|
1. The [repo owners](OWNERS) will respond to your issue promptly.
|
|
1. If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above).
|
|
1. Fork the desired repo, develop and test your code changes.
|
|
1. Submit a pull request.
|
|
|
|
## Test locally
|
|
|
|
Run the command `make test` to test the changes locally.
|