Skip to content

Standardize ee-apps HTTPRoute chart support to preserve rule fields like timeouts #406

Description

@wuhuizuo

Summary

ee-apps currently has 4 charts that render Gateway API HTTPRoute resources:

  • charts/cloudevents-server
  • charts/dl
  • charts/publisher
  • charts/tibuild-v2

These 4 charts all use the same HTTPRoute template shape, and they all drop rule-level fields other than matches and filters.

That means users cannot actually configure spec.rules[].timeouts, even if they put it in values. This is already causing operational friction for large streaming/download routes where Envoy/Gateway request timeout needs to be disabled or tuned.

Problem

Current templates only preserve:

  • spec.parentRefs
  • spec.hostnames
  • spec.rules[].matches
  • spec.rules[].filters
  • a hardcoded single backendRef pointing to the chart service

They do not preserve other valid rule-level fields such as:

  • spec.rules[].timeouts
  • spec.rules[].name
  • future/extended fields added by Gateway API implementations

So values like this:

httpRoute:
  enabled: true
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      timeouts:
        request: 0s

render into an HTTPRoute without the timeouts block.

Evidence

Affected templates:

  • charts/cloudevents-server/templates/httproute.yaml
  • charts/dl/templates/httproute.yaml
  • charts/publisher/templates/httproute.yaml
  • charts/tibuild-v2/templates/httproute.yaml

All 4 templates currently have the same pattern:

rules:
  {{- range .Values.httpRoute.rules }}
  {{- with .matches }}
  - matches:
    {{- toYaml . | nindent 8 }}
  {{- end }}
  {{- with .filters }}
    filters:
    {{- toYaml . | nindent 8 }}
  {{- end }}
    backendRefs:
      - name: {{ $fullName }}
        port: {{ $svcPort }}
        weight: 1
  {{- end }}

A quick render check confirms timeouts is silently dropped for all 4 charts.

Why this matters

For routes serving large downloads, uploads, or long-lived streaming responses, default proxy/gateway request timeouts are often wrong.

A concrete case is dl: we needed to set HTTPRoute.spec.rules[].timeouts.request: 0s to avoid large artifact downloads being cut off behind Envoy Gateway.

Because the chart template cannot render timeouts, downstream manifests had to work around it outside the chart instead of using normal chart values.

Proposed fix

Standardize all in-house HTTPRoute chart templates to preserve arbitrary rule-level fields while still owning the backend service reference.

A practical pattern is:

rules:
{{- range .Values.httpRoute.rules }}
- {{- toYaml (omit . "backendRefs") | nindent 2 }}
  backendRefs:
    - name: {{ $fullName }}
      port: {{ $svcPort }}
{{- end }}

This keeps the chart-controlled backend wiring, while allowing values to specify:

  • timeouts
  • name
  • matches
  • filters
  • future rule-level fields without more chart changes

It would also be good to standardize extra metadata support across these charts:

  • httpRoute.labels
  • httpRoute.annotations

Acceptance criteria

  • All 4 charts above can render httpRoute.rules[].timeouts.request.
  • Existing matches and filters behavior remains compatible.
  • Charts continue to own the backend service reference instead of requiring callers to specify it.
  • Add/extend chart tests to cover a rule containing timeouts.request: 0s.
  • Prefer one shared implementation style across all ee-apps charts with HTTPRoute support.

Nice to have

  • Add a small doc/example in each chart values file showing a long-lived route example with:
timeouts:
  request: 0s

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions