feat(ytdlp-web-player): Gateway-API as an alternative to the Ingress
Group 3 of the #114 sweep, last chart - and the one that carried the group-2 pattern this sweep was told to look for. It reads ingress.enabled OUTSIDE its Ingress template, in ytdlp-web-player.validate, and in Gateway mode ingress.enabled is false by construction, so that guard would have gone silent. Fixed with ytdlp-web-player.published = ingress.enabled OR httpRoute.enabled - the freesailarr.published / sure.publishedOverTls shape, identical to ingress.enabled while httpRoute.enabled is false, which is why it changes no existing render. AND THE GUARD IS NEEDED MORE IN GATEWAY MODE, NOT LESS. It refuses to publish the application and the oauth2-proxy on the same host: - In INGRESS mode the consequence of ignoring it is loud: ingress-nginx's admission webhook rejects the second Ingress and the Fleet bundle goes to ErrApplied. - In GATEWAY mode THE WEBHOOK NEVER FIRES. It compares Ingress objects with Ingress objects, and an HTTPRoute is a different kind - so nothing rejects anything, both objects stay valid, and one hostname is served over two data paths that are NOT equivalent: the proxy's Ingress goes through AUTHENTICATION and this chart's HTTPRoute goes straight to the application. Which one a client reaches depends on what DNS resolves to. That is an authentication bypass that comes and goes with a DNS record and that no Kubernetes object reports. So the Gateway-mode abort has its own message saying exactly that. Both messages exercised, plus the collision reached through httpRoute.hostnames rather than through the ingress.domain fallback, and the guard still firing when only the Deployment is rendered. THE SUBCHART HAS NO GATEWAY SUPPORT, and this chart cannot give it one - upstream's chart is consumed as it comes (README, "Chart dependencies"). It renders an Ingress or nothing. So in the RECOMMENDED configuration, where the proxy sits in the data path and owns the host, the publishing object is the SUBCHART'S INGRESS in both of this chart's modes, and turning httpRoute on buys nothing. The route is for the proxy-disabled case, or for the application on a host of its own - which is the documented unauthenticated bypass. Said in the template header, in values.yaml, in the schema and in the proxy branch of NOTES.txt, because someone migrating hosts will otherwise set the value and wonder why nothing moved. The 16k proxy-buffer-size this chart recommends is NOT lost by this switch, and that needed stating rather than assuming: it belongs on the PROXY's Ingress (oauth2-proxy.ingress.annotations) as the second half of the 4kB session-cookie trap, and the subchart keeps rendering an Ingress. This chart's own ingress.annotations default is {} and it sets nothing but the cert-manager annotation, so there is no chart-side annotation loss to name. CORRECTED CLAIM: values.yaml and the schema both said that everything the Ingress needs is read only inside its template, so switching it off freed BOTH ingress.domain and ingress.clusterIssuer. clusterIssuer is still freed; domain is now read by the HTTPRoute, so it is freed only with both modes off. The reason the claim was made still holds and is kept - the application has no base-URL setting and builds no absolute links. NOTHING WAS MEASURED ON A LIVE INGRESS OF THIS CHART, because there is none. Measured 2026-10-12: the release runs in namespace jlab-player with both Deployments Ready, and NOT ONE of the cluster's 23 Ingress objects is in that namespace - neither this chart's nor the subchart's. What publishes it instead could not be determined: this workspace's identity may not list httproutes or secrets, so neither a hand-written HTTPRoute nor the release's Helm values are readable. Recorded as the open question it is, in values.yaml and in the overlay, rather than guessed at. Minor: additive, defaults unchanged. Empty helm template diff against origin/main with ci/ytdlp-web-player/test-values.yaml. Part of #114
This commit is contained in:
1 parent
b10800da2a
commit
e4b41577ae
7 files changed
+504
-36
No files matched your search
@@ -232,11 +232,18 @@ storage:
|
||||
cacheSizeLimit: null
|
||||
|
||||
ingress:
|
||||
# Gates this chart's own Ingress. Everything the Ingress needs is read only
|
||||
# inside its template - the application itself needs no hostname of its own
|
||||
# (no base-URL setting, no absolute links, no url_for(_external=True)), so
|
||||
# switching the Ingress off frees BOTH ingress.domain and
|
||||
# ingress.clusterIssuer instead of only the issuer.
|
||||
# Gates this chart's own Ingress. MUTUALLY EXCLUSIVE WITH httpRoute.enabled -
|
||||
# the render aborts when both are true, and the message names both value
|
||||
# paths.
|
||||
#
|
||||
# CORRECTED WITH THE GATEWAY-API SUPPORT (Gitea #114): this used to say that
|
||||
# everything the Ingress needs is read only inside its template, and that
|
||||
# switching the Ingress off therefore freed BOTH ingress.domain and
|
||||
# ingress.clusterIssuer. The second half still holds - the application needs
|
||||
# no hostname of its own (no base-URL setting, no absolute links, no
|
||||
# url_for(_external=True)) and this mode renders no Certificate, so
|
||||
# clusterIssuer is still freed. But ingress.domain is now read by the
|
||||
# HTTPRoute as well, so it is freed only when BOTH modes are off.
|
||||
#
|
||||
# WHO OWNS THE HOST, WITH THE PROXY ENABLED: the proxy sits in the data path,
|
||||
# so with oauth2-proxy.enabled=true the Ingress belongs to the PROXY
|
||||
@@ -252,8 +259,89 @@ ingress:
|
||||
className: nginx
|
||||
# Extra annotations for the Ingress; merged with the cert-manager
|
||||
# cluster-issuer annotation the chart always sets.
|
||||
#
|
||||
# INERT IN GATEWAY MODE - the Gateway API has no annotation channel for
|
||||
# controller behaviour. Note which annotation this is NOT about: the 16k
|
||||
# proxy-buffer-size this chart recommends belongs on the PROXY's Ingress
|
||||
# (oauth2-proxy.ingress.annotations), and the subchart keeps rendering an
|
||||
# Ingress in either mode, so that one is unaffected by the switch.
|
||||
annotations: {}
|
||||
|
||||
# THE GATEWAY-API ALTERNATIVE TO THE INGRESS (Gitea #114).
|
||||
#
|
||||
# Mutually exclusive with ingress.enabled - the render aborts when both are
|
||||
# true. The chart renders ONLY an HTTPRoute with parentRefs: no Gateway, no
|
||||
# class, no Certificate, and no implementation-specific policy object. Class
|
||||
# and certificate sit on the Gateway and its listeners and belong to the
|
||||
# platform (cluster-config).
|
||||
#
|
||||
# BEFORE SWITCHING THIS ON, KNOW WHAT IT DOES NOT DO. The oauth2-proxy
|
||||
# SUBCHART HAS NO GATEWAY SUPPORT and this chart cannot give it one - upstream's
|
||||
# chart is consumed as it comes (README, "Chart dependencies"), so it renders an
|
||||
# Ingress or nothing. In the RECOMMENDED configuration, where the proxy sits in
|
||||
# the data path and owns the host while this chart's own routing object is off,
|
||||
# the object that publishes the release is THE SUBCHART'S INGRESS whatever this
|
||||
# value says. Turning httpRoute on there buys nothing.
|
||||
#
|
||||
# This route is for the other two cases:
|
||||
# - the proxy switched off (oauth2-proxy.enabled: false), so this chart
|
||||
# publishes the application itself;
|
||||
# - the application on a host of ITS OWN beside the proxy's host, which is
|
||||
# allowed and means exactly what it says: an unauthenticated way past the
|
||||
# proxy.
|
||||
#
|
||||
# AND THE HOST GUARD IS SHARPER IN THIS MODE, NOT WEAKER. If this chart and the
|
||||
# proxy's Ingress claim the SAME host:
|
||||
# - in Ingress mode ingress-nginx's admission webhook rejects the second
|
||||
# object loudly (the Fleet bundle goes to ErrApplied);
|
||||
# - in Gateway mode the webhook NEVER FIRES - it compares Ingress objects
|
||||
# with Ingress objects, and an HTTPRoute is a different kind. Both objects
|
||||
# stay valid and one hostname is served over two data paths that are NOT
|
||||
# equivalent: the proxy's Ingress goes through authentication, this chart's
|
||||
# HTTPRoute goes straight to the application. Which one a client reaches
|
||||
# depends on DNS, so it is an authentication bypass that comes and goes
|
||||
# with a record and that nothing in Kubernetes reports.
|
||||
# The chart therefore refuses to render that combination in BOTH modes, via the
|
||||
# ytdlp-web-player.published helper (ingress.enabled OR httpRoute.enabled).
|
||||
# Before #114 that guard asked ingress.enabled, which is false by construction
|
||||
# in Gateway mode - it would have gone silent exactly where it matters most.
|
||||
#
|
||||
# NOTHING WAS MEASURED ON A LIVE INGRESS OF THIS CHART, because there is none.
|
||||
# Checked 2026-10-12: the release runs in namespace jlab-player with both
|
||||
# Deployments Ready, and not one of the cluster's 23 Ingress objects is in that
|
||||
# namespace - neither this chart's nor the subchart's. What publishes it
|
||||
# instead could not be determined from this workspace (its identity may not
|
||||
# list httproutes or secrets). An open question, not a guess.
|
||||
#
|
||||
# THE GATEWAY-API CRDs MUST BE PRESENT. The chart cannot detect them
|
||||
# (.Capabilities.APIVersions is unreliable at template time) and an HTTPRoute
|
||||
# without them fails at install, so this is a value and not a guess.
|
||||
httpRoute:
|
||||
enabled: false
|
||||
|
||||
# The Gateway(s) the route attaches to - a platform object, usually in
|
||||
# another namespace, whose listener must allow this namespace in
|
||||
# allowedRoutes. Entries are the Gateway API's ParentReference (name, and
|
||||
# optionally namespace, sectionName, port, group, kind), passed through
|
||||
# unchanged:
|
||||
#
|
||||
# parentRefs:
|
||||
# - name: public
|
||||
# namespace: gateway
|
||||
# sectionName: https
|
||||
#
|
||||
# REQUIRED while httpRoute.enabled is true - the render aborts on an empty
|
||||
# list, because a route without a parent is created, is valid and routes
|
||||
# nothing, with no event to say so.
|
||||
parentRefs: []
|
||||
|
||||
# Empty means [ingress.domain], so the hostname has one source of truth. Set
|
||||
# explicitly only to publish under a different or an additional name - which
|
||||
# is how a migration from the Ingress runs, and also how the application is
|
||||
# given a host of its own beside the proxy's. The host guard reads this list
|
||||
# too, so a hostname set here that the proxy's Ingress also claims is caught.
|
||||
hostnames: []
|
||||
|
||||
# --- oauth2-proxy subchart -------------------------------------------------
|
||||
#
|
||||
# Everything below this line is passed to the oauth2-proxy chart
|
||||
|
||||
Reference in new issue
Block a user