jklein
4b2bde505d
Three issues on one chart, bundled because they share values.yaml, values.schema.json and the version line, and because the first half of #11 lives in the same template as #101. Gitea #11, first half: the consume CronJob's schedule was rendered bare, so a schedule in the commonest cron notation there is - a star, a slash, an interval - aborted the render with a YAML parse error pointing at the template while the operator's value appeared nowhere in the message. Quoting it in the values file does not help; Helm passes the content through. Reproduced before the fix, at the line the issue names, and fixed with | quote. Gitea #11, second half: secrets.oidcSecretRef is removed, values and schema both. No template ever read it, so no OnePasswordItem was created and nothing reached the pod - the quiet kind of defect that looks like successful configuration. It is not reimplemented, and the reason is in paperless: the whole OIDC configuration travels in one json environment variable with no _FILE variant, so a secretKeyRef cannot substitute a fragment into it. The operational question is answered by #83 - Keycloak marks a client public per client, so nothing forces a confidential one here. In the same breath, oidc.provider.tokenAuthMethod is restricted to "none". Its comment named client_secret_basic as the example, which asks the provider for an authentication this chart cannot perform: it configures no client secret and cannot. The two values read together looked like a working secret setup, and the symptom was a login dying at the callback with invalid_client. No live release sets it (measured against all three instances). Gitea #112 asked for an extraEnv and the chart already had the standard additive env block - the issue was measured against a deployed 12.2.0 and read only the top-level keys. What was actually broken is the block itself: it rendered its operand bare, so a "*"-leading value aborted the render and "true" or "0755" arrived as a bool or an integer, which the API server rejects after a green render. It is brought to the repository's documented quoted form (template-chart carries the rule), which is what makes an arbitrary PAPERLESS_* variable settable in practice. PAPERLESS_LOGGING_DIR is documented as the worked example, with the cross-reference it needs: the root cause is the NFS-exported RWX data volume in jk-cluster-config #360 and this does not fix it - it only moves the log off that volume. The two Ingress upload-size annotations had the same bare render and are quoted too. Gitea #101: the consume mover now runs on the node of the StatefulSet pod, via a required podAffinity on its label. It mounts the RWX consume volume, and Longhorn's CSI driver refuses that mount unless it finds a workload pod in Pending, so a mover on another node left the StatefulSet node's kubelet retrying every two minutes - 291 events in 10 hours in both releases with SMB on, none in the release without the CronJob. A static nodeSelector would be wrong because the StatefulSet pod is not pinned either, and preferred would reproduce the bug more rarely and harder to find. The cost of a required term is handled rather than left open: concurrencyPolicy: Forbid, a startingDeadlineSeconds that also keeps the controller away from its 100-missed-schedules stop, and an activeDeadlineSeconds that fails a job which cannot be placed instead of leaving one Pending pod per schedule. scaleDown already suspends the CronJob; what remains is paperless.replicas: 0 with SMB on, which now reports a bounded, visible failure. successfulJobsHistoryLimit is deliberately untouched: Longhorn's check asks for the existence of a Pending pod, not the absence of Succeeded ones, so those three pods are the error message's evidence and not its cause. Side defect fixed on the way: every read of smbConnection.cron dereferenced the block directly, so an override that had erased it aborted with a nil-pointer error naming an internal template path instead of falling back to the defaults this chart promises everywhere else. Measured on origin/main; all reads now go through a merged-defaults helper that preserves an explicit false. Major: a value is removed and fails the strict schema afterwards, and runtime placement changes. Fixes #11 Fixes #101 Fixes #112
90 lines
4.8 KiB
YAML
90 lines
4.8 KiB
YAML
apiVersion: v2
|
|
name: paperless-ngx
|
|
description: A Helm chart to deploy Paperless-NGX on Kubernetes
|
|
icon: https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/dev/src-ui/src/apple-touch-icon.png
|
|
|
|
type: application
|
|
|
|
version: 13.0.0+up3.2.1
|
|
|
|
appVersion: 3.2.1
|
|
|
|
maintainers:
|
|
- name: jklein
|
|
|
|
# The third chart in this repo with a dependency (after ytdlp-web-player and
|
|
# stalwart). README, "Chart dependencies", holds the bar a dependency has to
|
|
# clear and the full price list; what is repeated here is only what is specific
|
|
# to THIS chart, because the generic half is already written down twice.
|
|
#
|
|
# WHY ONE HERE. paperless-ngx cannot run without a Redis: PAPERLESS_REDIS is
|
|
# the Celery broker, and without it the web UI comes up looking healthy while
|
|
# consumption, OCR, the scheduled tasks and the index updates never run. So
|
|
# every installation needs one, and before this block the only way to have one
|
|
# was a second Helm release whose address lived in a 1Password item and in
|
|
# neither chart.
|
|
#
|
|
# WHY IT IS OFF BY DEFAULT: an installation that already has a Redis (or wants
|
|
# a shared one, which is what secrets.redisSecretRef' key-prefix field exists
|
|
# for) points redis-connection-url at it, and this dependency renders nothing.
|
|
# The subchart is the path for an installation that has none.
|
|
#
|
|
# THE SUBCHART IS OUR OWN valkey CHART, resolved from the published index - not
|
|
# upstream's. So README guideline 14.2 ("we consume their chart as it comes")
|
|
# does not apply and there are no third-party defaults to leave unpatched: the
|
|
# subchart follows this repo's conventions because it IS this repo's chart.
|
|
# What does apply in full is the subchart being invisible to everything
|
|
# downstream that watches Helm release versions, and the PR-ordering hazard
|
|
# below.
|
|
dependencies:
|
|
- name: valkey
|
|
# KEEP THIS VERSION MOVING - it is the only path a Valkey update has into a
|
|
# cluster through this chart. The version declared here is baked into our
|
|
# packaged .tgz, so anything watching Helm release versions (Fleet
|
|
# included) sees only "paperless-ngx": a new valkey chart, a security fix
|
|
# included, arrives ONLY when this line is raised and a new paperless-ngx
|
|
# version is published. Nothing reports the gap.
|
|
#
|
|
# Renovate's BUILT-IN helmv3 manager reads this block and opens the PR, and
|
|
# ci/renovate-bump-chart.sh bumps this chart's patch version, which is what
|
|
# actually ships it. No customManagers entry exists or would help - that
|
|
# manager is for exactly this case, where repository and version sit
|
|
# together in one file. Measured for Gitea #65 against our self-hosted
|
|
# index (Renovate 44.132.2, dry run with the dependency pinned low:
|
|
# newVersion "1.0.0+up9.1.2.alpine", versioning "helm"), so the chain is
|
|
# proven for this registry and this build-metadata suffix and was not
|
|
# re-measured here.
|
|
#
|
|
# Independent of appVersion: raising it is a patch or minor bump of this
|
|
# chart and is never tied to the paperless-ngx image.
|
|
version: "1.0.0+up9.1.2.alpine"
|
|
# Our own published index, and the READ path only - anonymously readable
|
|
# (measured), so ci/helm-dependencies.sh needs no credential and was not
|
|
# touched. The publish target and its credentials still live in 1Password
|
|
# and appear nowhere in this repository; see README, "CI/CD".
|
|
repository: "https://git.jk-dev.de/api/packages/jlab-cluster/helm"
|
|
# Off by default, so a plain install renders none of its objects.
|
|
#
|
|
# NOT "valkey.enabled", AND THAT IS NOT A STYLE CHOICE. Everything under
|
|
# the "valkey:" key is handed to the subchart as ITS values and validated
|
|
# against ITS schema, and our valkey chart ships additionalProperties:
|
|
# false with no "enabled" property:
|
|
# Error: values don't meet the specifications of the schema(s) in the
|
|
# following chart(s): valkey: - at '': additional properties 'enabled'
|
|
# not allowed
|
|
# Worse, Helm skips a DISABLED subchart's schema validation, so with the
|
|
# default of false that error would stay invisible through lint, render and
|
|
# install-test and surface only for whoever first switched it on - the one
|
|
# case the value exists for. The condition is therefore a key of OUR OWN,
|
|
# outside the subchart's value subtree.
|
|
condition: valkeySubchart.enabled
|
|
#
|
|
# !!! NEVER CHANGE valkey/ AND THIS CHART IN THE SAME PULL REQUEST !!!
|
|
#
|
|
# The dependency resolves out of the PUBLISHED index, not out of the working
|
|
# tree, and valkey/ is published only by a push to main that touches it. A
|
|
# single PR carrying both therefore runs lint, package, render AND the
|
|
# install-test against the OLD valkey .tgz and goes green about an artifact
|
|
# that is not the one in the diff. Two consecutive pull requests: change
|
|
# valkey/, merge, let it publish, then raise the version here. README, "Chart
|
|
# dependencies", and the wiki's valkey page carry the long form. |