helm-charts/rss-bridge/templates/NOTES.txt

{{- $httpRoute := .Values.httpRoute | default dict -}}
{{- $hostnames := $httpRoute.hostnames | default list -}}
RSS-Bridge {{ .Chart.AppVersion }} was installed as release "{{ .Release.Name }}".

{{ if .Values.ingress.enabled -}}
ACCESS - INGRESS MODE (ingress.enabled: true, httpRoute.enabled: false)

Reachable at:
{{ range $entry := .Values.ingress.hosts }}  https://{{ $entry.host }}
{{ end }}
Each host serves the same instance. Certificates are issued by the
cert-manager cluster issuer "{{ .Values.ingress.clusterIssuer }}" into these secrets:
{{ range $secret := (fromYaml (include "rss-bridge.tlsGroups" (dict "hosts" .Values.ingress.hosts "root" $))).order }}  {{ $secret }}
{{ end }}
Hosts sharing a secret name share one certificate with several SANs; hosts with
distinct names get one certificate each. That grouping is what keeps the three
grown certificates of this installation on their existing secret names.
{{- else if $httpRoute.enabled -}}
ACCESS - GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)

Reachable at:
{{ range $hostnames }}  https://{{ . }}
{{ end }}
All of these names are served by ONE HTTPRoute ({{ .Release.Name }}-{{ .Chart.Name }}-httproute), because
nothing differs between them: one rule, PathPrefix "/", one backend. Adding or
removing a name is an edit to httpRoute.hostnames and nothing else.

This release renders that route 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 of them is missing the hostnames above simply
do not answer:

  1. The Gateway-API CRDs. Without them this install would have failed, so
     they are present - nothing to check.
  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 is
     visible 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 what a working attachment looks like. An empty
     status means no controller has looked at the route at all.
  3. A TLS certificate for every hostname above, on the Gateway's listener.
     ingress.clusterIssuer is NOT used in this mode and is not required - the
     chart renders no Certificate here, so none of the tls-* secrets listed by
     the Ingress mode exists and there is nothing for cert-manager to do on
     behalf of this release.

NOTHING THIS CHART DID IN INGRESS MODE IS LOST HERE

Worth stating plainly, because it is not the usual case in this repository:
most charts switched to the Gateway API give something up, since
ingress.annotations has no counterpart in this API and an operator's
annotation often carried real behaviour. This chart's live Ingress was measured
before the switch and carries no nginx.ingress.kubernetes.io annotation at all -
no body-size limit, no buffer sizes, no CORS, no rewrite, no auth. So there is
no compensation to re-create at the Gateway and no behaviour to miss.

Two things do become inert, and neither is a loss:

  * ingress.annotations - gone in this mode, as everywhere. Empty here.
  * The TLS secret grouping (rss-bridge.tlsGroups, and the per-host
    ingress.hosts[].tlsSecretName it reads) - with the certificate on the
    listener there is nothing left to group. This is the chart's most
    intricate Ingress-mode machinery and it simply has no job here.

What is NOT demonstrated: that traffic actually flows. No Gateway controller
runs in CI, so no HTTPRoute of this chart has ever reached "Accepted: True"
there, and the install-test installs the Ingress mode rather than this one.
Check the route status above after the first install rather than assuming it
attached.
{{- else -}}
ACCESS - NEITHER INGRESS NOR HTTPROUTE

ingress.enabled and httpRoute.enabled are both false, so this release has no
Ingress, no HTTPRoute and no certificate; ingress.hosts, ingress.clusterIssuer
and httpRoute.hostnames are not needed. Reach the instance with:

  kubectl --namespace {{ .Release.Namespace }} port-forward svc/{{ .Release.Name }}-{{ .Chart.Name }}-service 8080:80

and open http://localhost:8080

To publish it instead, set either ingress.enabled=true with ingress.hosts and
ingress.clusterIssuer, or httpRoute.enabled=true with httpRoute.hostnames and
httpRoute.parentRefs.
{{- end }}

Enabled bridges ({{ len .Values.whitelist }} entr{{ if eq (len .Values.whitelist) 1 }}y{{ else }}ies{{ end }} in whitelist.txt):
{{ range $entry := .Values.whitelist }}  {{ $entry }}
{{ end }}
{{- if has "*" .Values.whitelist }}
"*" enables every bridge the image ships. Narrow it down by listing bridge
names in the "whitelist" value.
{{- end }}

Useful to know:

  * Health endpoint: /?action=health - a fixed JSON document that touches
    neither the cache nor any remote site. All three probes use it.
  * Changing the "whitelist" value rolls the pod: the deployment carries a
    checksum over the ConfigMap, because a subPath mount would otherwise never
    reach the running container.
  * The feed cache lives in an emptyDir at /app/cache and is therefore
    deliberately lost on every restart. RSS-Bridge refills it on demand; it
    holds only fetched feeds, no configuration and no user data.
  * The container runs read-only and non-root as uid 33 (www-data).
{{- if .Values.scaleDown }}

WARNING: scaleDown is true, so this release is running with 0 replicas.
Set scaleDown=false to bring it back up.
{{- end }}