feat(wiki): deploy the .NET wiki service next to the Python wiki-index #940

2026-09-24T10:28:37Z

claude-bot commented

2026-09-24 10:28:37 +00:00

Phase 1 deployment of the wiki service (konairius/Wiki, PR #1 merged there; design kubernetes/PROPOSAL-wiki-web-api.md, PR #939). Runs alongside the Python wiki-index until parity in the cluster is confirmed; nothing is removed here.

kubernetes/apps/wiki/: PVC (1Gi ceph-block), Deployment pinned to gitea.renner.uno/konairius/wiki:build.1790245544 (commit c4e193b; anonymous pull verified), non-root, read-only root fs with an emptyDir at /tmp, startup probe on /ready with room for the ~10 min first sync, readiness /ready, liveness /health; Service; two ExternalSecrets (Gitea token + webhook secret from the existing apps/ai/wiki-index key, API keys from the new apps/ai/wiki-api-keys); Ingress wiki.renner.uno LAN-only behind the existing BasicAuth credential until the Authentik gate arrives in phase 2.
kubernetes/clusters/homelab/wiki.yaml: Flux Kustomization, wait + 25 min timeout, depends on llama-server (wiki-embed).
ai-ns.yaml: CNP wiki admitting Traefik and Gitea on 8080. No OpenBao egress; the pod has no OpenBao role.

Verification after merge: pod Ready after the first sync, /api/v1/status shows 1741 notes and all adapters ok, wiki_rank.py --probe-index against https://wiki.renner.uno, then the Gitea webhook on k.renner/notes gets a second target for the new service.

🤖 Generated with Claude Code

Phase 1 deployment of the wiki service (konairius/Wiki, PR #1 merged there; design `kubernetes/PROPOSAL-wiki-web-api.md`, PR #939). Runs alongside the Python `wiki-index` until parity in the cluster is confirmed; nothing is removed here. - `kubernetes/apps/wiki/`: PVC (1Gi ceph-block), Deployment pinned to `gitea.renner.uno/konairius/wiki:build.1790245544` (commit c4e193b; anonymous pull verified), non-root, read-only root fs with an emptyDir at /tmp, startup probe on `/ready` with room for the ~10 min first sync, readiness `/ready`, liveness `/health`; Service; two ExternalSecrets (Gitea token + webhook secret from the existing `apps/ai/wiki-index` key, API keys from the new `apps/ai/wiki-api-keys`); Ingress `wiki.renner.uno` LAN-only behind the existing BasicAuth credential until the Authentik gate arrives in phase 2. - `kubernetes/clusters/homelab/wiki.yaml`: Flux Kustomization, wait + 25 min timeout, depends on llama-server (wiki-embed). - `ai-ns.yaml`: CNP `wiki` admitting Traefik and Gitea on 8080. No OpenBao egress; the pod has no OpenBao role. Verification after merge: pod Ready after the first sync, `/api/v1/status` shows 1741 notes and all adapters ok, `wiki_rank.py --probe-index` against `https://wiki.renner.uno`, then the Gitea webhook on k.renner/notes gets a second target for the new service. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-09-24 10:28:38 +00:00

feat(wiki): deploy the .NET wiki service next to the Python wiki-index

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

0cfc4dc486

PVC, Deployment (build.1790245544), Service, ExternalSecrets for the
shared Gitea token/webhook secret and the API keys, LAN-only ingress
wiki.renner.uno behind BasicAuth, Flux Kustomization, CNP admitting
Traefik and Gitea. No OpenBao access from the pod.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

k.renner merged commit ad152d2d16 into master

2026-09-24 10:29:44 +00:00

k.renner referenced this issue from a commit

2026-09-24 10:29:45 +00:00

Merge pull request 'feat(wiki): deploy the .NET wiki service next to the Python wiki-index' (#940) from feat/wiki-service-manifests into master

review-bot reviewed

2026-09-24 10:32:12 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit 0cfc4dc4868085d059046840577b1c343fb76a56.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Adds a new wiki app (kubernetes/apps/wiki/, its Flux Kustomization, and an ai namespace CiliumNetworkPolicy) that deploys the .NET konairius/wiki service alongside the existing Python wiki-index, reusing the latter's Gitea credentials and BasicAuth secret. The manifests closely mirror the established wiki-index app (same security context, probe shape, PVC pattern, CNP shape, Flux dependsOn), and the cross-checks below (ClusterSecretStore namespace allow-list, ceph-block StorageClass, llama-server/infrastructure* Kustomization names, apps/kustomization.yaml not double-including this path) all check out. No blocking issues found.

🟡 Suggestions

kubernetes/apps/wiki/ingress.yaml:12 — the new wiki-basic-auth Middleware points at the wiki-index-basic-auth Secret, which is created by the separate wiki-index Flux Kustomization (kubernetes/apps/wiki-index/ingress.yaml), not by anything in this PR. kubernetes/clusters/homelab/wiki.yaml's dependsOn doesn't include wiki-index, so on a from-scratch cluster bootstrap there's no ordering guarantee that the secret exists before wiki's Middleware is applied (Traefik would just 401/500 until wiki-index reconciles — self-healing, not a hard failure). More importantly, this creates a soft coupling for the future: the PR body says the Python wiki-index will eventually be retired once parity is confirmed, and whoever does that decommission needs to remember wiki is still borrowing its BasicAuth secret, or wiki silently loses ingress auth. Worth a comment here (or in the wiki-index removal follow-up) noting the dependency, since nothing in the code makes it discoverable from the wiki-index side.
kubernetes/apps/wiki/externalsecrets.yaml:158-166 — wiki-gitea pulls gitea_token/webhook_secret from the existing apps/ai/wiki-index OpenBao key. That key's fields were presumably named for the Python service's own Vault client (wiki-index reads it directly via BAO_SECRET_PATH, not through an ExternalSecret today), so this PR is a new, second consumer asserting the same field names. That's plausible but not verifiable from this repo — worth confirming the ExternalSecret actually synced (kubectl get externalsecret wiki-gitea -n ai) rather than assuming the field names line up, per the PR's own verification checklist.

🟢 Nits

kubernetes/apps/wiki/deployment.yaml:49-51 — runAsUser/runAsGroup: 65534 (nobody/nogroup) matches wiki-index's convention, but worth double-checking the konairius/wiki image's default filesystem ownership on /data actually works under that UID on a fresh ceph-block PVC (same class of risk wiki-index already carries, not new here).

Tests

No automated tests apply to this change — it's pure Kubernetes/Flux manifest addition, consistent with how wiki-index and other apps in this repo are reviewed (manifest correctness + in-cluster verification after merge). The PR body lays out a concrete post-merge verification plan (pod readiness, /api/v1/status note count, wiki_rank.py --probe-index, webhook wiring), which is the appropriate substitute here.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `0cfc4dc4868085d059046840577b1c343fb76a56`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Adds a new `wiki` app (kubernetes/apps/wiki/, its Flux Kustomization, and an `ai` namespace `CiliumNetworkPolicy`) that deploys the .NET `konairius/wiki` service alongside the existing Python `wiki-index`, reusing the latter's Gitea credentials and BasicAuth secret. The manifests closely mirror the established `wiki-index` app (same security context, probe shape, PVC pattern, CNP shape, Flux `dependsOn`), and the cross-checks below (ClusterSecretStore namespace allow-list, `ceph-block` StorageClass, `llama-server`/`infrastructure*` Kustomization names, `apps/kustomization.yaml` not double-including this path) all check out. No blocking issues found. ## 🟡 Suggestions - `kubernetes/apps/wiki/ingress.yaml:12` — the new `wiki-basic-auth` Middleware points at the `wiki-index-basic-auth` Secret, which is created by the *separate* `wiki-index` Flux Kustomization (`kubernetes/apps/wiki-index/ingress.yaml`), not by anything in this PR. `kubernetes/clusters/homelab/wiki.yaml`'s `dependsOn` doesn't include `wiki-index`, so on a from-scratch cluster bootstrap there's no ordering guarantee that the secret exists before `wiki`'s Middleware is applied (Traefik would just 401/500 until `wiki-index` reconciles — self-healing, not a hard failure). More importantly, this creates a soft coupling for the future: the PR body says the Python `wiki-index` will eventually be retired once parity is confirmed, and whoever does that decommission needs to remember `wiki` is still borrowing its BasicAuth secret, or `wiki` silently loses ingress auth. Worth a comment here (or in the `wiki-index` removal follow-up) noting the dependency, since nothing in the code makes it discoverable from the `wiki-index` side. - `kubernetes/apps/wiki/externalsecrets.yaml:158-166` — `wiki-gitea` pulls `gitea_token`/`webhook_secret` from the existing `apps/ai/wiki-index` OpenBao key. That key's fields were presumably named for the Python service's own Vault client (`wiki-index` reads it directly via `BAO_SECRET_PATH`, not through an ExternalSecret today), so this PR is a new, second consumer asserting the same field names. That's plausible but not verifiable from this repo — worth confirming the ExternalSecret actually synced (`kubectl get externalsecret wiki-gitea -n ai`) rather than assuming the field names line up, per the PR's own verification checklist. ## 🟢 Nits - `kubernetes/apps/wiki/deployment.yaml:49-51` — `runAsUser/runAsGroup: 65534` (nobody/nogroup) matches `wiki-index`'s convention, but worth double-checking the `konairius/wiki` image's default filesystem ownership on `/data` actually works under that UID on a fresh `ceph-block` PVC (same class of risk `wiki-index` already carries, not new here). ## Tests No automated tests apply to this change — it's pure Kubernetes/Flux manifest addition, consistent with how `wiki-index` and other apps in this repo are reviewed (manifest correctness + in-cluster verification after merge). The PR body lays out a concrete post-merge verification plan (pod readiness, `/api/v1/status` note count, `wiki_rank.py --probe-index`, webhook wiring), which is the appropriate substitute here. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#940