#1397 [apps] [foundationdb] Initial support for FoundationDB operator

[Anonymous]

Originally created by: insignia96

What this PR does

This PR adds initial support to begin testing managed FoundationDB instances in Cozystack. Addresses [#824]

Release note

[apps] Add FoundationDB as a managed app for tenants
[foundationdb] Add fdb-kubernetes-operator with v2.13.0

Summary by CodeRabbit

• New Features

• Added managed FoundationDB app and operator with Helm charts to deploy configurable clusters (storage, resources, backups, monitoring, workload monitor).

• Documentation

• Added comprehensive README, default values, and a JSON Schema for chart configuration and validation.

• Tests

• Added end-to-end test provisioning a FoundationDB cluster, validating rollout, health, monitoring artifacts, security context, storage claims, and cleanup.

• Chores

• Added packaging targets, operator charts and CRDs, API schema registration, versions map entry, and bundle release entries.

[Anonymous]

Originally posted by: coderabbitai[bot]

Walkthrough

Adds a FoundationDB application Helm chart (templates, values, schema, docs, Makefile), bundles the FoundationDB Kubernetes operator (charts, CRDs, operator templates, Makefile), registers FoundationDB resource definitions and versions in Cozystack API/platform bundles, and adds an end-to-end BATs test validating deployment lifecycle.

Changes

Cohort / File(s)	Summary
E2E test hack/e2e-apps/foundationdb.bats	New BATs test provisioning a FoundationDB CR in tenant-test, waits for HelmRelease/FoundationDBCluster readiness, asserts pods/WorkloadMonitor/ConfigMap/health/securityContext/PVCs, and verifies deletion/cleanup with polling/timeouts.
FoundationDB app: chart scaffold & docs packages/apps/foundationdb/.helmignore, packages/apps/foundationdb/Chart.yaml, packages/apps/foundationdb/Makefile, packages/apps/foundationdb/README.md, packages/apps/foundationdb/charts/cozy-lib	Adds chart metadata, helmignore, Makefile (includes packaging and generate target), README, and cozy-lib reference.
FoundationDB app: values & schema packages/apps/foundationdb/values.yaml, packages/apps/foundationdb/values.schema.json	Adds Helm defaults and a JSON Schema validating cluster/version/processCounts/storage/resources/backup/monitoring/securityContext/imageType/automaticReplacements.
FoundationDB app: templates packages/apps/foundationdb/templates/_resources.tpl, .../cluster.yaml, .../backup.yaml, .../workloadmonitor.yaml, .../dashboard-resourcemap.yaml, .../role.yaml, .../rolebinding.yaml, .../serviceaccount.yaml	Adds helper templates (resources/labels/chart/minReplicas), FoundationDBCluster template, conditional backup Secret+FoundationDBBackup, WorkloadMonitor template, dashboard resourcemap ConfigMap, and RBAC/serviceaccount templates.
Cozystack API & versions packages/system/cozystack-api/openapi-schemas/foundationdb.json, packages/system/cozystack-api/templates/cozystack-resource-definitions.yaml, packages/apps/versions_map	Links chart values.schema.json into API schemas, registers CozystackResourceDefinition entries (foundationdb and kafka), and adds foundationdb 0.1.0 HEAD to versions_map.
FDB Operator: chart scaffold & sync packages/system/foundationdb-operator/.helmignore, packages/system/foundationdb-operator/Chart.yaml, packages/system/foundationdb-operator/Makefile	Adds operator chart metadata, helmignore, and an update Makefile to sync upstream fdb-kubernetes-operator charts/CRDs (tag v2.13.0).
FDB Operator: bundled chart & templates packages/system/foundationdb-operator/charts/fdb-operator/Chart.yaml, .../crds/...foundationdbrestores.yaml, .../templates/_helpers.tpl, .../templates/manager/deployment.yaml, .../templates/rbac/*, .../templates/serviceaccount.yaml, .../templates/NOTES.txt, .../values.yaml	Adds bundled operator chart metadata, FoundationDBRestore CRD, helpers, manager Deployment (with init containers for multiple FDB versions), RBAC (Role/ClusterRole and bindings), ServiceAccount template, NOTES, and operator defaults.
System wiring: bundles & dashboard packages/system/foundationdb-operator/values.yaml, packages/core/platform/bundles/*.yaml, packages/system/dashboard/values.yaml	Adds system-level operator defaults, registers foundationdb-operator releases in distro/paas bundles, and adds FoundationDB entry to dashboard config.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor User
  participant API as Cozystack API
  participant Helm as Helm Controller
  participant K8s as Kubernetes
  participant OP as FDB Operator
  participant FDB as FoundationDB Cluster

  User->>API: Create FoundationDB CozystackResource
  API->>Helm: Ensure HelmRelease (foundationdb chart)
  Helm->>K8s: Render & apply FoundationDBCluster, WorkloadMonitor, Secrets (if backup)
  K8s->>OP: FoundationDBCluster CR created/updated
  OP->>K8s: Create/manage Pods, PVCs, Services
  K8s->>OP: Pod/PVC status events
  OP->>K8s: Update FoundationDBCluster status (health/available)
  Helm-->>API: HelmRelease becomes Ready
  API-->>User: Resource reports Ready

  rect rgba(230,240,255,0.35)
  note right of Helm: Conditional: backup and resourcemap emitted when enabled
  end

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• [[#1321]](https://github.com/cozystack/cozystack/issues/1321) — Related Makefile/tooling changes invoking cozyvalues-gen for chart README/schema generation.
• [[#1400]](https://github.com/cozystack/cozystack/issues/1400) — Related API/resource wiring and HelmRelease → managed-app mapping logic.
• [[#1316]](https://github.com/cozystack/cozystack/issues/1316) — Related Makefile generate-target and packaging tooling changes.

Suggested reviewers

• kvaps
• lllamnyp
• klinch0

Poem

I thump my paw—charts hop in line,
CRDs sprout roots, operators shine.
Monitors hum as pods awake,
PVCs nest and backups bake.
Hoppy deploys—FoundationDB delight! 🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

| Check name | Status | Explanation | | :----------------: | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. | | Title Check | ✅ Passed | The title succinctly and accurately describes the primary change—adding initial support for the FoundationDB operator—and follows the repository’s tagging convention ([apps] [foundationdb]). It is concise, specific, and informative for reviewers scanning the commit history. | | Docstring Coverage | ✅ Passed | No functions found in the changes. Docstring coverage check skipped. |

✨ Finishing touches

- [ ] 📝 Generate Docstrings

🧪 Generate unit tests

- [ ] Create PR with unit tests - [ ] Post copyable unit tests in a comment

[!TIP]

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

yaml reviews: pre_merge_checks: custom_checks: - name: "Undocumented Breaking Changes" mode: "warning" instructions: | Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

- [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Anonymous]

Originally posted by: lllamnyp

Hi @insignia96 !

Thanks for taking the time to contribute to Cozystack. This looks really cool! Ping us up once you're ready to mark this PR as ready for review and we'll be happy to test your addition.

[Anonymous]

Originally posted by: lllamnyp

By the way, could you please run make generate for the Makefile in ./packages/system/cozystack-api and update ./packages/system/cozystack-api/templates/cozystack-resource-definitions.yaml with a config for the new app? The format there should be pretty self-explanatory.

[Anonymous]

Originally posted by: insignia96

Thanks @lllamnyp ! I appreciate the feedback. This is still a WIP as I am working on getting an environment for testing. I was wondering about generating the API parts so that is very helpful. I am still working on figuring out how to use my bare-metal nodes to run the tests. Can you run the actual E2E tests on the buildkit or do you use some other method to run the tests on a bare-metal node in the cluster?

[Anonymous]

Originally posted by: lllamnyp

If you were to mark this as ready for review, we would be able to run tests on our runners. We do in fact run tests with buildkit, essentially, we have a powerful metal server that fires up three qemu-kvm nodes for cozystack and runs everything inside of them. If you already have a Cozystack cluster running, you could install your new build on top of that, by running make apply from a number of directories in your local environment. Can't give exact steps off the top of my head, I'll see if I can get you some more detailed instructions.

[Anonymous]

Originally posted by: insignia96

@lllamnyp I have marked this as ready for review after making the changes you mentioned. I do have one bare metal node in my cluster that could work to run the test setup in the repo. I am working on getting that set up to test on my end as well.

[Anonymous]

Originally posted by: insignia96

@lllamnyp Okay, as of this latest commit, I think this is in a good working state and I have run the tests in my cluster to verify it seems to work. Backups have not been tested yet, but the core functionality seems to be there in the rest. It is probably ready if you all would like to test it as well.

Future roadmap items would be:

• Exporting Prometheus metrics and adding a Grafana dashboard
• Adding a self-signed issuer and TLS for the database, but this is complicated by the need for the operator to have access to the certs to speak with the database and manage it.
• Better tests for more complex database types and multi-region support.
• Disaster recovery backup types, streaming to a remote FoundationDB cluster or acting as a target.
• Update the values to make the storage claims more configurable, to allow stateless pods and storage pods to have different sizes.

[Anonymous]

Originally posted by: lllamnyp

@lllamnyp I have marked this as ready for review after making the changes you mentioned. I do have one bare metal node in my cluster that could work to run the test setup in the repo. I am working on getting that set up to test on my end as well.

Great! We'll get this tested.

[Anonymous]

Originally posted by: lllamnyp

@insignia96 could you rebase your branch against main to trigger the workflow for the newest CI config?

[Anonymous]

Originally posted by: insignia96

@lllamnyp Okay, this should be done now.

As far as the backups and other roadmap items I mentioned, I am running into a bit of an issue with the backup and TLS functions and I wanted to solicit the advice of the maintainers on the best way to handle this for Cozystack. FoundationDB and the operator have some interesting constraints on credentials and certificates. In order to run commands against the database it is managing when TLS is used, the operator needs to have access to the cluster CA cert and a client cert/key pair, and for backups the operator needs access to the same blob credentials secret that the backup-agent pods in the actual database also need. Since the operator fundamentally lacks support for the kind of multi-tenancy Cozystack is designed for, because it cannot handle more than one TLS configuration or blob credential file at a time, I am thinking the best solution may be to migrate the operator to an extra feature that can be installed per-namespace, to allow isolation between tenant secrets and CAs, but the need to have the secrets in both parent and child namespaces and the operators limitations might cause an issue with properly implementing tenant inheritance it is implemented for other extra features. The operator can only be in global mode or watching one namespace. If this approach sounds okay, I could rework this to move the operator from a system namespace to an extra feature.

As it stands now, the chart as-is would require only some minor updates to allow cluster administrators to enable backups and TLS, but it would not be possible for the operator to manage any other clusters that are non-TLS or using different certs, and the cluster administrator would have to manually manage the secrets for the operator in the system-level opearator namespace similar to the process for backing up tenant Kubernetes using Velero.

[Anonymous]

Originally posted by: lllamnyp

Sorry for taking a while, I was away for the latter half of last week. Looks like we're still struggling to get external PRs working properly. I'll test this manually and will come back with feedback soon.