5d10b0245820c8cf8760b913e3b7f6af02aa463d
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a9ca5302de
|
feat(paperless-ngx): optional valkey subchart, password from the redis item
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 12s
Validate Helm Charts / Build paperless-ngx (pull_request) Successful in 6s
Validate Helm Charts / Trivy config paperless-ngx (pull_request) Successful in 22s
Install-test / Install-test paperless-ngx (pull_request) Successful in 3m31s
Validate Helm Charts / Install-test (pull_request) Successful in 3m31s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 10s
Publish Paperless-NGX Helm Chart / Publish Paperless-NGX Helm Chart (push) Successful in 10s
SonarQube Analysis / SonarQube Analysis (push) Successful in 33s
paperless-ngx cannot run without a Redis - PAPERLESS_REDIS is the Celery broker - so every installation needed a second Helm release whose address lived in a 1Password item and in neither chart. This adds our own published valkey chart as an optional dependency, off by default and gated on valkeySubchart.enabled (not valkey.enabled, which the subchart's strict schema rejects and which Helm would only have complained about for whoever first switched it on). Additive, default behaviour unchanged: minor, 12.1.3+up3.2.1 -> 12.2.0+up3.2.1. Configured as a QUEUE (PVC + noeviction, the subchart's defaults), unlike stalwart's cache. Read off the 3.2.1 source rather than assumed: one PAPERLESS_REDIS url serves five consumers - the Celery broker, the result backend (Redis in 3.x, the database before), the channels pub/sub layer and two Django caches. allkeys-lru would not be a trade here but actively wrong, because LRU evicts typeless across the whole keyspace and a backlog of waiting consume tasks is exactly what it reads as cold; a dropped task is a document silently never processed. The price, named in values.yaml rather than smoothed over: two of the five consumers are caches, so a full instance refuses writes - new tasks included - and the answer is memory sizing, not a policy change. All three cache-like consumers are TTL-bounded, which is what keeps that price small. The password comes from the SAME item as the Redis connection, in a third field auth-conf holding the complete line "requirepass <password>". It cannot DEFAULT to secrets.redisSecretRef, and that is a property of Helm, not an omission: a values.yaml is never templated and a parent cannot compute a subchart's value. Measured - a template expression there lands verbatim in the subchart's itemPath and fails as a YAML parse error naming neither the value nor the cause. Forgetting it is therefore caught in values.schema.json, by a conditional rule rather than a fail() in a template. Also measured, and the reason: Helm renders a subchart's templates BEFORE the parent's, so a guard in this chart loses the race to the subchart's own required(), which reports "secrets.authSecretRef" and cannot know the path belongs to the redis item. A check that cannot fire is the mistake found while testing #77, so the first draft of that guard was removed rather than shipped. The schema runs before any rendering and names /valkey/secrets/authSecretRef. One trap found while testing and closed here: "valkeySubchart: null" DELETES the key, Helm then cannot resolve the condition path and treats the dependency as ENABLED - so erasing the switch turned the subchart on with no password set. Unlike every other block in this chart (issue #99), that one is rejected by the schema instead of defaulting. The install-test now runs with the subchart ON and the throwaway redis Deployment removed: the url in the fixtures names ci-valkey-service, so the bundled Valkey is the broker the release actually uses. #65 covered this path by a render only - deliberately, since an unused Valkey would have made that test look like it covered clustering. This is the first real installation of the valkey-subchart path. Documented, not glossed: the password now sits in that item twice and a rotation has to touch both fields; with the subchart on the vault url is a mandatory step, not a hint; and a OnePasswordItem materializes every field of its item, so both Secrets carry all three keys - untidy, harmless, and written down so nobody "tidies it up". Fixes #78 |
||
|
|
bf02dab364
|
paperless-ngx: NOTES.txt and the #157 render fix (12.1.0+up3.0.5)
Two additive changes, no rendered Kubernetes object changes except the resource limits that previously aborted the render. #157 — a bare integer resource value from about 1e6 upwards aborted the render. The null-safe fallbacks pass values through fromYaml, which parses every number as float64, and Go's "%v" switches float64 to exponential notation from that size on: 1048576 became "1.048576e+06", which is not a valid Kubernetes quantity. The canonical correction from the issue is taken over verbatim: multiplyQuantity formats its input and its non-integer product through a new formatNumber helper instead of "%v". The toYaml/fromYaml round trip is not touched — it was just unified across all charts and it is not the cause. This chart has two resource paths and both were affected: paperless.resources (sfs) and smbConnection.cron.resources (consume CronJob). Measured on both before and after, plus the 65536 fallback probe, which is unchanged. #43 — NOTES.txt. Prints what an operator would otherwise read out of the templates: the rendered URL and that ingress.domain also becomes PAPERLESS_URL, the field names each 1Password item must carry (including that the database field is "server" and that "username" is used as both admin login and admin mail), and that secrets.oidcSecretRef is read by no template at all. The conditional sections cover the SMB consume strecke, scaleDown, OIDC, Tika and the barcode settings actually in effect. The traps it names are the ones this chart really has: no checksum annotation anywhere, so rotating an item's content restarts nothing; Redis failing silently while the UI stays green; the 600s startup budget against migrations and the 3.x index rebuild; the consume PVC being hardcoded to 1Gi; the CronJob moving only top-level *.pdf and having no probes (the documented exception); and a cron schedule starting with "*" aborting the render. README is deliberately left alone: the line listing the charts with a NOTES.txt is pulled up once at the end of the programme, so that parallel NOTES PRs do not collide on it. Teil von #157 Teil von #43 |