server.route.enabled cannot be tpl-rendered, so an umbrella cannot drive it from a global switch

[tada5hi]

Problem

Every field of server.route is tpl-rendered except the one that decides whether the route exists:

Field	tpl-rendered
hostnames	yes
parentRefs	yes
matches	yes (0.2.2)
filters	yes (0.2.2)
annotations	yes
enabled	no — plain boolean

templates/server/httproute.yaml gates on and .Values.server.enabled .Values.server.route.enabled, and values.schema.json types server.route.enabled as "type": "boolean", so a template string is rejected before rendering.

Why it matters

An umbrella chart typically has one switch that turns on Gateway API routing for every service it bundles. With 0.2.2 an umbrella can express the whole route through values — and that is genuinely all of it, path matches and filters included — but still cannot tie its existence to that switch.

This is not a values-plumbing problem: global is visible inside the subchart, so the umbrella's switch is already reachable from the value. It is only the type that blocks it:

authup:
 server:
 route:
 enabled: '{{ .Values.global.flameHub.gatewayApi.enabled }}' # rejected: got string, want boolean

Concrete consumer

PrivateAIM/flame-hub bundles authup with five sibling services behind one global.flameHub.gatewayApi.enabled. It has just migrated its authup route from a hand-written HTTPRoute to server.route (PrivateAIM/helm#176) — the 0.2.2 matches/filters cover it exactly, including a URLRewrite stripping /auth and an ExtensionRef to an NGINX Gateway Fabric SnippetsFilter.

The one regression is that authup alone must now be switched on separately:

authup:
 server:
 route:
 enabled: true # cannot follow global.flameHub.gatewayApi.enabled like the other five

Its templates/gateway.yaml builds one Gateway listener per enabled service, so authup's entry is now the odd one out, reading .Values.authup.server.route.enabled while its siblings read (or $globalEnabled .Values.<svc>.gatewayApi.enabled).

Proposed fix

Accept a templated boolean, the way a number of charts treat conditionally-enabled subresources:

# values.yaml
route:
 # -- Create a Gateway API HTTPRoute for server-core (tpl-rendered; a string
 # rendering to "true" enables it, so an umbrella can drive this from a global)
 enabled: false

{{- $routeEnabled := .Values.server.route.enabled }}
{{- if kindIs "string" $routeEnabled }}
{{- $routeEnabled = eq (trim (include "authup.tplvalues.render" (dict "value" $routeEnabled "context" $))) "true" }}
{{- end }}
{{- if and .Values.server.enabled $routeEnabled }}

plus "type": ["boolean", "string"] in values.schema.json for server.route.enabled and adminConsole.route.enabled.

The same argument applies to server.ingress.enabled and adminConsole.ingress.enabled, though those matter less — an umbrella that owns the hostname usually owns the ingress too.

If a templated boolean is unappealing, an alternative that solves the same problem is a chart-level global.authup.routeEnabled-style toggle, but the tpl route reuses machinery the chart already has everywhere else and adds no new vocabulary.