jklein
e4b41577ae
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
65 lines
3.4 KiB
YAML
65 lines
3.4 KiB
YAML
# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
|
|
#
|
|
# Its one job is to put this chart into Gateway mode, because the convention
|
|
# ships with httpRoute.enabled: false and the test would otherwise be green
|
|
# over nothing. A chart that has an overlay here and still renders no
|
|
# HTTPRoute FAILS the test - that is the whole point of the file existing.
|
|
#
|
|
# An overlay and not a change to ci/ytdlp-web-player/test-values.yaml: the
|
|
# install-test runs exactly ONE configuration per chart, and this chart's
|
|
# fixture is the one that resolves and installs the oauth2-proxy SUBCHART.
|
|
# Trading its Ingress for a CRD schema check that cyberchef's fixture already
|
|
# performs against the real Gateway-API CRDs would be a bad swap. The install
|
|
# keeps the Ingress; the route is held here, at render level.
|
|
#
|
|
# ingress.enabled: false is not optional here - ingress.enabled defaults to
|
|
# TRUE in this chart, so without this line the chart aborts its own render with
|
|
# both modes on.
|
|
#
|
|
# THE SUBCHART IS LEFT DISABLED, as the fixture has it, and that is deliberate
|
|
# rather than lazy. The oauth2-proxy chart HAS NO GATEWAY-API SUPPORT - it
|
|
# renders an Ingress or nothing - so switching it on here would add a second
|
|
# object this test does not look at, while the thing worth exercising in
|
|
# Gateway mode is this chart's own route. The interesting interaction between
|
|
# the two (one hostname claimed by the proxy's Ingress AND by this chart's
|
|
# HTTPRoute, which the ingress-nginx admission webhook cannot catch because the
|
|
# kinds differ) is a RENDER-FAILURE path: the chart refuses it. This test only
|
|
# runs renders it expects to succeed, so that guard was exercised by hand
|
|
# instead - see the PR.
|
|
#
|
|
# WHAT THIS OVERLAY COVERS:
|
|
#
|
|
# - ingress.domain comes from the fixture (ytdlp-web-player.example.com), so
|
|
# the route renders with its hostname from that single source of truth.
|
|
# httpRoute.hostnames stays empty on purpose: the fallback is the path an
|
|
# installation will actually use.
|
|
# - the backendRef is checked against the application Service of the same
|
|
# render, by PORT NUMBER rather than by the name "http" the Ingress uses,
|
|
# because backendRefs takes a PortNumber. That number also has to agree
|
|
# with ytdlp-web-player.appServiceAddress, which is what the proxy gets as
|
|
# its upstream - three places, and this overlay holds two of them together.
|
|
#
|
|
# No URLRewrite filter is rendered by this chart in either mode, so the #118
|
|
# prefix/redirect assurance has no precondition to meet here.
|
|
#
|
|
# NOT covered here, and it cannot be:
|
|
#
|
|
# - that the hostname answers. No Gateway controller runs in CI and no route
|
|
# reaches "Accepted: True".
|
|
# - that authentication is in front of the application. With the proxy off
|
|
# this route IS the unauthenticated path, which is correct for a fixture
|
|
# and is exactly what NOTES.txt warns about for a real installation.
|
|
# - anything about how this release is published in the real cluster. There
|
|
# is no live Ingress of this chart to compare against: 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. What
|
|
# publishes it could not be determined from the workspace.
|
|
ingress:
|
|
enabled: false
|
|
httpRoute:
|
|
enabled: true
|
|
parentRefs:
|
|
- name: public
|
|
namespace: gateway
|
|
sectionName: https
|