feat(homelab): self-host Plane issue tracker - #2007
Conversation
|
This change is part of the following stack: Change managed by git-spice. |
## Summary Deploy Plane Commercial as a private, issue-tracking-only service through the official `plane-enterprise` Helm chart. ## Changes - Pin chart `3.1.0` and app `v3.0.1`, with generated Helm types. - Add the local Plane infrastructure chart and layered ArgoCD applications. - Configure native authentication, local Postgres/Redis/RabbitMQ on `zfs-ssd`, and disable vendor ingress, MinIO, OpenSearch, PI, and runner services. - Route Plane through a private Tailscale Ingress at `plane.tailnet-1a49.ts.net`. - Store attachments in the SeaweedFS `plane-attachments` bucket through the storage proxy. - Add the dedicated 1Password-backed `plane-secrets` item and explicit Velero PVC policy entries. - Add synthesis tests and durable deployment plan documentation. ## Verification - Full cdk8s tests: 330 passed, 14 expected skips. - Helm compatibility render passed, including Plane. - Typecheck, lint, Prettier, gitleaks, 1Password validation, and OpenTofu validation passed. - Vendor manifest inspection confirmed the four Plane stateful claim templates, `plane-secrets` references, no vendor Ingress, and no PI/runner resources. ## Deployment follow-up Live ArgoCD sync/health, Tailscale HTTPS access, native login, issue workflows, attachment persistence, tailnet-only access, and Velero discovery still need operator verification after the change is published to the GitOps branch.
PR Summary by QodoSelf-host Plane Commercial in homelab with private Tailscale ingress
AI Description
Diagram
High-Level Assessment
Files changed (15)
|
c15e64a to
5b7fa91
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c15e64ab8a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Deploy the free Plane Commercial tier with the official `plane-enterprise` | ||
| Helm chart, pinned to chart `3.1.0` and app `v3.0.1`. Use Plane for private | ||
| issue tracking only; leave wiki/pages available but unused. Access is through | ||
| the Tailscale Kubernetes ingress at `plane.tailnet-1a49.ts.net`, with no public | ||
| Funnel exposure. |
There was a problem hiding this comment.
Document Plane in the human architecture wiki
This introduces a persistent, operator-managed service with a new tailnet ingress and storage boundary, but records it only in an in-progress workflow plan; the inspected human-facing wiki has no Plane or corresponding homelab system-map entry. Add or update the nearest homelab wiki page so the deployed architecture and its private-access boundary remain discoverable alongside the code.
AGENTS.md reference: AGENTS.md:L68-L69
Useful? React with 👍 / 👎.
Code Review by Qodo
1. Plane PSA enforcement unspecified
|
| "pod-security.kubernetes.io/audit": "restricted", | ||
| "pod-security.kubernetes.io/warn": "restricted", | ||
| }, |
There was a problem hiding this comment.
1. Plane psa enforcement unspecified 🐞 Bug ☼ Reliability
createPlaneChart() sets only PSA audit/warn labels on the plane Namespace but leaves enforce behavior to the cluster default, while the Plane chart documentation explicitly calls out that bundled local infra (postgres/redis/rabbitmq/etc.) is not covered by the PSA-restricted securityContext. This makes the Plane rollout non-deterministic across clusters: if PSA restricted is enforced by default, the bundled infra pods can be rejected and the deployment will not reach healthy.
Agent Prompt
### Issue description
The `plane` namespace is labeled with PSA `audit`/`warn` only, which leaves `enforce` behavior to whatever the cluster default is. The Plane chart’s own documentation states that its hardened `securityContext` does **not** apply to bundled local infrastructure services (postgres/redis/rabbitmq/minio/opensearch), so a restricted-enforcing cluster can block those pods.
### Issue Context
This PR enables bundled local services (`local_setup: true`) for Plane’s postgres/redis/rabbitmq, so the namespace PSA enforcement choice directly affects whether Plane can run.
### Fix Focus Areas
- packages/homelab/src/cdk8s/src/cdk8s-charts/plane.ts[20-31]
- packages/homelab/src/cdk8s/src/resources/argo-applications/plane.ts[24-36]
- packages/homelab/src/cdk8s/generated/helm/plane-enterprise.types.ts[2988-3001]
### Requested change
Add an explicit `pod-security.kubernetes.io/enforce` label for the `plane` namespace that matches the intended policy (e.g. `privileged` if you want to allow the bundled infra pods to run) while keeping `audit`/`warn` as `restricted` for visibility.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| return new Application(chart, "plane-app", { | ||
| metadata: { | ||
| name: PLANE_RELEASE, | ||
| }, |
There was a problem hiding this comment.
2. No plane app sync ordering 🐞 Bug ☼ Reliability
The PR introduces two independent Argo CD Applications (plane-infrastructure and plane) without any sync-wave/dependency ordering, even though the vendor chart is configured to use a Secret name that is materialized by the infrastructure app’s OnePasswordItem. This can produce an initially degraded rollout (pods/jobs failing due to missing Secret data) until the infrastructure app and 1Password operator reconcile.
Agent Prompt
### Issue description
Two Argo CD Applications are added for Plane: one for infrastructure (namespace/ingress/1Password secret bridge) and one for the vendor Helm chart. There is no explicit ordering between them, but the vendor chart is configured to reference `plane-secrets`, which is produced asynchronously by the infra app via `OnePasswordItem`.
### Issue Context
Argo CD may reconcile Applications in any order; without ordering, the vendor workloads can start before `plane-secrets` exists, resulting in transient failures or degraded health until the infra app and the 1Password operator catch up.
### Fix Focus Areas
- packages/homelab/src/cdk8s/src/resources/argo-applications/plane.ts[71-96]
- packages/homelab/src/cdk8s/src/resources/argo-applications/plane.ts[99-121]
- packages/homelab/src/cdk8s/src/cdk8s-charts/plane.ts[33-41]
- packages/homelab/src/cdk8s/src/cdk8s-charts/apps.ts[132-136]
### Requested change
Add `metadata.annotations["argocd.argoproj.io/sync-wave"]` to both Application CRs so `plane-infrastructure` syncs earlier than `plane` (e.g. infra = `-1`, vendor = `0`). This makes the rollout deterministic and reduces degraded/failed initial syncs due to missing secrets/ingress.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
No description provided.