Files
helm-charts/outline/templates/NOTES.txt
T
jklein bd1fdc09a0
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 14s
Validate Helm Charts / Selector match (pull_request) Successful in 14s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 14s
Validate Helm Charts / Build freesailarr (pull_request) Successful in 7s
Validate Helm Charts / Build outline (pull_request) Successful in 7s
Validate Helm Charts / Build paperless-ngx (pull_request) Successful in 8s
Validate Helm Charts / Build zipline (pull_request) Successful in 8s
Validate Helm Charts / Build calibre-web-automated (pull_request) Successful in 7s
Validate Helm Charts / Trivy config calibre-web-automated (pull_request) Successful in 19s
Validate Helm Charts / Trivy config freesailarr (pull_request) Successful in 24s
Validate Helm Charts / Trivy config outline (pull_request) Successful in 17s
Validate Helm Charts / Trivy config paperless-ngx (pull_request) Successful in 19s
Validate Helm Charts / Trivy config zipline (pull_request) Successful in 19s
Install-test / Install-test calibre-web-automated (pull_request) Successful in 2m11s
Install-test / Install-test freesailarr (pull_request) Successful in 3m55s
Install-test / Install-test outline (pull_request) Successful in 2m44s
Install-test / Install-test paperless-ngx (pull_request) Successful in 3m52s
Install-test / Install-test zipline (pull_request) Successful in 2m6s
Validate Helm Charts / Install-test (pull_request) Successful in 14m50s
feat: Gateway-API as an alternative to the Ingress in five annotation charts
Group 2 of the #114 sweep: the charts whose behaviour hangs off an nginx
annotation - calibre-web-automated, outline, paperless-ngx, zipline
(proxy-body-size) and freesailarr (rewrite-target).

Each gets the form the pilot (cyberchef, PR #115) fixed and group 1 (PR #116)
repeated: an httpRoute block off by default, a template rendering ONLY an
HTTPRoute with parentRefs - no Gateway, no gatewayClassName, no Certificate, no
implementation-specific policy object - render aborts on both modes at once
(naming both value paths), on an empty parentRefs and on a missing hostname,
empty hostnames meaning [ingress.domain], a schema entry closed against unknown
keys with an open parentRef definition, and a NOTES.txt that names the active
mode and what the mode costs.

Minor, additive, defaults unchanged: `helm template` with each chart's CI values
is byte-identical to origin/main for all five.

The upload limit is DOCUMENTED, not rebuilt (decision 2 of the issue). The
Gateway API knows no body size; a policy object would bind the chart to one
implementation. So the Gateway branch of NOTES.txt says, per chart and in the
chart's own terms, that the value is NOT ENFORCED and names where to set it: an
e-book library (calibre), an upload service (zipline), the web-UI half of the
document intake while the consume directory keeps no limit at all (paperless),
and the open #12 pair (outline).

Four findings that were not in the plan, each argued in the file it changes:

  freesailarr gated freesailarr.sharedIngressApps on ingress.enabled, and that
  list is read by the <APP>__SERVER__URLBASE variables as well as by the routing
  objects. In Gateway mode it would have come out EMPTY while the route served
  radarr, sonarr and prowlarr under their prefixes: UrlBase unset, assets and API
  calls linked at the host root, broken UI behind a Ready pod. The helper's two
  guards (seerr/mediathekarr only at "/", no duplicate paths) would have gone
  unenforced there too. Fixed with freesailarr.published (ingress.enabled OR
  httpRoute.enabled) - the same shape as sure.publishedOverTls in group 1, and
  identical to ingress.enabled while httpRoute.enabled is false. Measured: on
  origin/main with ingress.enabled: false the render emits ZERO URLBASE
  variables; with this change in Gateway mode it emits three.

  paperless-ngx was the last chart in the repository rendering its Ingress
  UNCONDITIONALLY. Without an ingress.enabled switch there is no second value
  path for the mutual-exclusion abort to name, and the Ingress plus its
  unconditional required() on clusterIssuer would have kept rendering in Gateway
  mode - a value demanded for nothing, which is issue #114's "Folge 1" and
  README guideline 12. The switch was added, defaulting to true, so the render is
  unchanged.

  paperless-ngx PAPERLESS_URL had no required() of its own: it relied on the
  Ingress template's, which stops firing the moment the Ingress is switchable.
  With httpRoute.hostnames set and ingress.domain empty it would have rendered
  "https://" and refused every login POST as a CSRF failure. It now carries its
  own required(), naming what the value is for.

  calibre-web-automated claimed, in values.yaml and in its schema, that
  ingress.domain is read nowhere but in the Ingress template. The HTTPRoute reads
  it, so the claim now holds only while both modes are off. Corrected rather than
  left standing - the same correction garage needed in group 1.

freesailarr is where the Gateway API is LESS machinery than what it replaces,
not a translation of it. rewrite-target applies per Ingress OBJECT, so
qBittorrent (no base path, prefix must be stripped) needed a second Ingress on
the shared host, which then had to repeat the first object's TLS secret name,
omit the cert-manager annotation conditionally so only one Certificate is
requested, and match an ImplementationSpecific regex path for the rewrite's
capture group. A URLRewrite filter applies per RULE: one route, one rule per
app, the filter on qBittorrent's rule, a plain PathPrefix. All four crutches
gone. It is also the only chart without httpRoute.hostnames - it has no
ingress.domain either, and a chart-global hostname list could not say which of
the ten apps it belonged to, so the hostnames stay in ingress.host and
<app>.ingress.host.

CI: one render overlay per chart under ci/httproute/, so the assertion is not
vacuum-green - ci/run-httproute-match-test.sh goes from 20 held assertions over
10 charts to 36 over 15. freesailarr's overlay moves bazarr onto a host of its
own, so the shared-host route AND the per-app route are both rendered; without
that the per-app branch would be exercised by nothing. The install-test fixtures
stay in Ingress mode: the install runs one configuration per chart, cyberchef
already pays that price against the real Gateway-API CRDs, and for paperless-ngx
that fixture is the only install of the valkey-subchart path anywhere.

README also carries a stale figure fixed here: the HTTPRoute test was still
documented at the pilot's 4 assertions over 2 charts, although group 1 had taken
it to 20 over 10.

Not proven, by construction: that traffic flows. No Gateway controller runs in
CI. Not run locally either: k3d, Docker, Trivy. The Gateway branch of NOTES.txt
is EXECUTED by the render test (a template error in it fails the job, verified)
but its text is printed by no pipeline stage - helm template does not emit
notes, and the install-test installs in Ingress mode.

Part of #114
2026-10-12 18:15:29 +00:00

238 lines
13 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
{{- $replicas := include "outline.replicas" (dict "scaleDown" .Values.scaleDown "replicas" .Values.outline.replicas) -}}
{{- $startup := fromYaml (include "outline.startupProbe" .Values.outline.startupProbe) -}}
{{- $upload := .Values.outline.maxUploadSize | toString -}}
{{- $httpRoute := .Values.httpRoute | default dict -}}
{{- $hostnames := $httpRoute.hostnames | default list -}}
{{- if not $hostnames -}}
{{- $hostnames = list .Values.ingress.domain -}}
{{- end -}}
Outline {{ .Chart.AppVersion }} — release {{ .Release.Name }} in namespace {{ .Release.Namespace }}.
{{- if .Values.ingress.enabled }}
ACCESS — INGRESS MODE (ingress.enabled: true, httpRoute.enabled: false)
https://{{ .Values.ingress.domain }}
The certificate is requested by cert-manager through the "{{ .Values.ingress.clusterIssuer }}"
cluster issuer. Until it has been issued the browser shows a warning; follow it with
kubectl -n {{ .Release.Namespace }} get certificate tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress
{{- else if $httpRoute.enabled }}
ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)
{{- range $hostnames }}
https://{{ . }}
{{- end }}
This release renders an HTTPRoute ({{ .Release.Name }}-{{ .Chart.Name }}-httproute) and NOTHING
else of the routing path — no Gateway, no class, no Certificate. Three things
therefore belong to the cluster and not to this chart, and if any is missing
the address above does not answer:
1. The Gateway-API CRDs. Without them this install would have failed.
2. The Gateway named in httpRoute.parentRefs
{{- range $httpRoute.parentRefs }}
{{ .name }}{{ if .namespace }} in namespace {{ .namespace }}{{ end }}{{ if .sectionName }}, listener {{ .sectionName }}{{ end }}
{{- end }}
must exist AND its listener must allow routes from this namespace
({{ .Release.Namespace }}) in allowedRoutes. A rejected attachment shows
up only in the route's status:
kubectl -n {{ .Release.Namespace }} get httproute {{ .Release.Name }}-{{ .Chart.Name }}-httproute -o yaml
Read status.parents[].conditions — "Accepted: True" and
"ResolvedRefs: True" is a working attachment. An empty status means no
controller has looked at the route at all.
3. The TLS certificate for the hostname, on the Gateway's listener.
ingress.clusterIssuer is NOT used in this mode and is not required: the
chart renders no Certificate, so there is no
tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress secret and nothing for cert-manager to do.
ingress.domain is still required in this mode and is {{ .Values.ingress.domain }}: it becomes
Outline's URL variable, which builds every generated link, every share URL
and the OIDC redirect URI. The route does not replace it. If you set
httpRoute.hostnames to a name ingress.domain does not carry, the route
publishes one host while the app hands out links for another — and an OIDC
login then fails on a redirect_uri the provider does not know. Set both
together.
ingress.annotations is inert in this mode: the Gateway API has no annotation
channel. WebSockets need none — Outline's realtime editing upgrades on the
same port and a plain HTTPRoute passes that through, exactly as the Ingress
did without an annotation.
{{- else }}
ACCESS — NEITHER INGRESS NOR HTTPROUTE
ingress.enabled and httpRoute.enabled are both false, so this release is not
published: no Ingress, no HTTPRoute and no certificate.
ingress.domain is still required: it becomes Outline's URL variable, which
builds every generated link, every share URL and the OIDC redirect URI.
Reach the instance inside the cluster with
kubectl -n {{ .Release.Namespace }} port-forward svc/{{ .Release.Name }}-{{ .Chart.Name }}-service 8080:80
and open http://localhost:8080. Links on the page will still point at
https://{{ .Values.ingress.domain }}/, and an OIDC login will only complete if
that host actually resolves for the browser.
{{- end }}
{{ if eq $replicas "0" }}
SCALED TO ZERO
{{ if .Values.scaleDown }}scaleDown: true{{ else }}outline.replicas: 0{{ end }} — the StatefulSet runs with replicas: 0, so the endpoint
above does not answer until you set it back and upgrade again. PVC, Secrets,
Service{{ if .Values.ingress.enabled }} and Ingress stay in place, so neither the uploads nor the
certificate are touched.{{ else if $httpRoute.enabled }} and HTTPRoute stay in place, so the uploads are not touched — the
route then resolves to a Service with no endpoints and the Gateway answers
its own error.{{ else }} and the uploads on the PVC stay in place.{{ end }}
{{ end }}
WHAT THE THREE 1PASSWORD ITEMS MUST CONTAIN
The chart creates OnePasswordItem CRs; the operator turns each into a
Kubernetes Secret whose keys are the FIELD NAMES of the 1Password item. A
missing field does not fail the install — the release goes through and the
pod then hangs in CreateContainerConfigError naming the key it could not
find (kubectl -n {{ .Release.Namespace }} describe pod).
secrets.configSecretRef → {{ .Values.secrets.configSecretRef }}
Secret {{ .Release.Name }}-{{ .Chart.Name }}-secret, fields:
outline-secret-key SECRET_KEY, 32 random bytes hex (openssl rand -hex 32)
outline-utils-secret UTILS_SECRET, a second, independent value
discovery-url OIDC issuer URL (the .well-known discovery endpoint)
client-id OIDC client id
client-secret OIDC client secret
secrets.dbSecretRef → {{ .Values.secrets.dbSecretRef }}
Secret {{ .Release.Name }}-{{ .Chart.Name }}-db-secret, field:
connection-url postgres://user:password@host:5432/database
secrets.redisSecretRef → {{ .Values.secrets.redisSecretRef }}
Secret {{ .Release.Name }}-{{ .Chart.Name }}-redis-secret, field:
connection-url redis://host:6379
On the identity provider's side the client needs this redirect URI:
https://{{ .Values.ingress.domain }}/auth/oidc.callback
The login button is labelled "{{ .Values.outline.oidc.displayName }}" (outline.oidc.displayName).
Nothing about OIDC is exercised before someone actually signs in, so a wrong
issuer, secret or redirect URI surfaces as a failed login on a healthy pod.
The first account to sign in creates the workspace and becomes its admin —
on a fresh install, sign in yourself before handing the URL to anyone.
CHANGING A SECRET'S CONTENT RESTARTS NOTHING
Helm never sees the content of a OnePasswordItem, so it cannot hash it, and
this chart carries no checksum annotation for secrets (it has no ConfigMap
either). Pointing a *SecretRef at a DIFFERENT item rolls the pods; editing a
value INSIDE the same item does not — the operator updates the Kubernetes
Secret while the running container keeps the old value in its environment.
After such a rotation:
kubectl -n {{ .Release.Namespace }} rollout restart statefulset/{{ .Release.Name }}-{{ .Chart.Name }}-sfs
Rotating outline-secret-key invalidates existing sessions; rotating it
without keeping the old value also makes previously encrypted data
unreadable. Rotate the database or Redis URL and the pod restarts into
whatever that new endpoint contains, empty or not.
POSTGRES AND REDIS ARE NOT PART OF THIS CHART
Both have to exist and be reachable before the first start. /_health checks
them, and all three probes use it, so a missing database does not produce a
useful error: the pod simply never turns Ready and the startup probe kills
it after about {{ mul $startup.failureThreshold $startup.periodSeconds }}s. Read the container log, not the pod events.
The chart pins PGSSLMODE=disable next to the connection URL. That fits a
Postgres reached over the cluster network; a database anywhere less trusted
needs TLS asked for explicitly, and this chart has no value for it — the
outline.env block below is the place to set it.
THE FIRST START MIGRATES, AND THE STARTUP PROBE IS THE CLOCK
Outline runs its database migrations when the container starts. The startup
probe grants {{ $startup.failureThreshold }} × {{ $startup.periodSeconds }}s = {{ mul $startup.failureThreshold $startup.periodSeconds }}s before the kubelet restarts the
container — and a restart lands in the middle of a migration. Raise
outline.startupProbe.failureThreshold BEFORE a large app-version jump or a
first import, not after the crash loop has started.
Back up the database before any app-version bump. Migrations are one-way; a
helm rollback returns the old image to a database the new one has already
rewritten.
ONE REPLICA, ONE VOLUME
Uploads are stored locally (FILE_STORAGE=local), on the ReadWriteOnce PVC
{{ .Release.Name }}-{{ .Chart.Name }}-pvc under /outline-data/data — there is no object storage in
this chart. That PVC is a plain chart object, not a StatefulSet
volumeClaimTemplate, so all replicas would share the single RWO volume and
the second pod usually never schedules.
{{- if gt (int $replicas) 1 }}
outline.replicas is {{ $replicas }}. Expect the extra pods to stay Pending on
"Multi-Attach error for volume" unless the storage class is genuinely RWX.
{{- end }}
BACKUP IS TWO THINGS AT THE SAME TIME
The database holds the documents and one row per attachment; the PVC holds
the attachment bytes. Restoring one without the other gives a wiki with
broken images or files nobody references. Snapshot them together.
Because the PVC is rendered by the chart, helm uninstall deletes it and the
uploads with it, unless the storage class reclaim policy says otherwise. The
external database survives that — which makes an accidental uninstall look
recoverable while the attachments are already gone.
{{- if .Values.ingress.enabled }}
TWO UPLOAD CEILINGS, THE SMALLER ONE WINS
outline.maxUploadSize {{ $upload }}{{ if regexMatch "^[0-9]+$" $upload }} bytes (~{{ div (int64 $upload) 1048576 }} MiB){{ else }} — Outline reads this as a plain byte count{{ end }}
ingress.maxUploadFileSize {{ .Values.ingress.maxUploadFileSize }}
The smaller of the two decides, and the Ingress limit fails the more
confusingly: a file above it never reaches Outline, so the user gets the
ingress controller's 413 page instead of a message from the app. With the
chart defaults the Ingress is the tighter of the two by a factor of ten.
Raise both, or neither.
{{- else if $httpRoute.enabled }}
YOUR UPLOAD CEILING IS NOT ingress.maxUploadFileSize ANY MORE — IT IS THE GATEWAY'S
outline.maxUploadSize {{ $upload }}{{ if regexMatch "^[0-9]+$" $upload }} bytes (~{{ div (int64 $upload) 1048576 }} MiB){{ else }} — Outline reads this as a plain byte count{{ end }}
ingress.maxUploadFileSize {{ .Values.ingress.maxUploadFileSize }} — NOT ENFORCED in this mode
The chart renders ingress.maxUploadFileSize into
nginx.ingress.kubernetes.io/proxy-body-size, and the Gateway API has NO
counterpart — it knows no body size at all, that is implementation-specific
policy — so this chart deliberately renders no policy object, which would
bind it to one implementation. The ceiling that actually bites is therefore
the smaller of outline.maxUploadSize and WHATEVER THE GATEWAY ENFORCES, and
the chart can only name the first of those two. Set the limit at the Gateway
or through its implementation's own policy object, next to the Gateway and
not here.
Read that next to Gitea #12, which is about exactly this pair: with the chart
defaults the two documented numbers are a factor of ten apart. In this mode
the ingress half is gone, so neither of them is necessarily the one that
decides — which moves that defect rather than fixing it. Check the Gateway's
own limit before trusting either number.
{{- else }}
UPLOAD CEILING
outline.maxUploadSize {{ $upload }}{{ if regexMatch "^[0-9]+$" $upload }} bytes (~{{ div (int64 $upload) 1048576 }} MiB){{ else }} — Outline reads this as a plain byte count{{ end }}
With neither routing mode on, this is the only limit the chart sets —
whatever proxy you put in front adds its own, usually much smaller,
body-size cap. ingress.maxUploadFileSize ({{ .Values.ingress.maxUploadFileSize }}) is rendered nowhere.
{{- end }}
THE CHART CONFIGURES NO MAIL
Outline sends invitations, document notifications and digest mails over
SMTP. This chart sets no SMTP_* variable at all, so those mails are quietly
never sent and nothing in the UI says so. The place to add them is
outline.env, which also supports the secretKeyRef form for the password.
{{- if .Values.outline.env }}
outline.env currently adds {{ len .Values.outline.env }} variable(s), rendered after the ones the chart
sets itself.
{{- end }}
{{- if has (.Values.outline.forceHttps | toString) (list "true" "1") }}
FORCE_HTTPS IS ON
outline.forceHttps is set. The chart defaults it to "false" because the
Ingress already terminates TLS and Outline trusts the forwarded protocol
header. Turned on, Outline redirects to https itself — which loops
endlessly if that header does not reach the pod.
{{- end }}