feat(helm): add Gateway API HTTPRoute support#20561
Conversation
Adds an opt-in HTTPRoute template to the Bytebase Helm chart following
the convention used by ArgoCD (argoproj/argo-helm) and the cis-devops
devops-chart.
New values block:
httpRoute:
enabled: false # opt-in; mutually exclusive with ingress
annotations: {}
parentRefs: [] # Gateway API parentReference list
hostnames: [] # virtual hostnames to match
rules: [] # custom rules; defaults to catch-all PathPrefix /
When httpRoute.rules is empty the template emits a single catch-all rule
(PathPrefix /) pointing at the bytebase-entrypoint Service on port 80,
which covers the common single-hostname case without requiring callers
to repeat boilerplate. Callers that need path splitting, header filters,
or timeout overrides set httpRoute.rules explicitly.
The backend Service port is 80 (targetPort 8080) — the HTTPRoute
backendRef always uses port 80 regardless of bytebase.option.port.
Example (preprod install):
httpRoute:
enabled: true
parentRefs:
- name: public
namespace: kube-system
sectionName: https
hostnames:
- bytebase.preprod.cisecurity.org
|
We require contributors to sign our Contributor License Agreement, and we don't have yours on file. In order for us to review and merge your code, please sign CLA and add your name to contributors list. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 08370a5f63
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| kind: HTTPRoute | ||
| metadata: | ||
| name: {{ .Release.Name }} | ||
| namespace: {{ .Release.Namespace }} |
There was a problem hiding this comment.
Render HTTPRoute into the overridden namespace
When namespaceOverride is set for the multi-namespace combined-chart path supported by bytebase.namespace, the Service is rendered in the override namespace (templates/service.yaml uses the helper), but this new HTTPRoute stays in .Release.Namespace. In that configuration the route cannot refer to the same-namespace bytebase-entrypoint backend Service unless users add unsupported cross-namespace backend wiring, so enabling httpRoute breaks traffic for namespace-overridden installs.
Useful? React with 👍 / 👎.
Use the bytebase.namespace helper (matching service.yaml) so the HTTPRoute lands in the same namespace as the bytebase-entrypoint Service when namespaceOverride is set; otherwise the same-namespace backendRef breaks.
|
We require contributors to sign our Contributor License Agreement, and we don't have yours on file. In order for us to review and merge your code, please sign CLA and add your name to contributors list. |
|
d-bytebase
left a comment
There was a problem hiding this comment.
Thanks for this — the opt-in HTTPRoute is clean and self-contained. I rendered all three cases (disabled / catch-all default / explicit rules) with helm template and helm lint passes; the backendRef port 80 correctly matches the bytebase-entrypoint Service. Two things worth fixing before merge (inline), plus a couple of optional nits below.
Should fix
- The "mutually exclusive with Ingress" wording in both
README.mdandvalues.yamlis inaccurate (see inline comments).
Optional
Chart.yamlis still at1.1.3. Adding a new template usually warrants a minor bump — does this repo bump the chart version per feature PR, or only at release time?weight: 1on a singlebackendRefis redundant (weight only matters when there are multiple backends). Harmless, but can be dropped.
| # ref: https://gateway-api.sigs.k8s.io/api-types/httproute/ | ||
| httpRoute: | ||
| # -- Enable HTTPRoute for Bytebase (Gateway API). Requires a Gateway API implementation in the cluster. | ||
| # Mutually exclusive with Ingress — enable one or the other, not both. |
There was a problem hiding this comment.
This chart ships no Ingress — there's no ingress.yaml template and no ingress values block (grep -i ingress over the chart returns nothing). Today it only exposes the bytebase-entrypoint ClusterIP Service and operators put their own Ingress/LB in front. So there's nothing in-chart for HTTPRoute to be "mutually exclusive" with — this HTTPRoute is actually the chart's first in-chart north-south route. The wording looks carried over from the argo chart referenced in the PR description.
Suggest rewording to something like:
# -- Enable a Gateway API HTTPRoute to expose Bytebase, instead of an
# externally-managed Ingress/LoadBalancer. Requires a Gateway API
# implementation in the cluster.| | `bytebase.persistence.storageClass` | Storage class for the persistent volume used by Bytebase. | "" | | ||
| | `bytebase.extraSecretMounts` | Additional Bytebase secret mounts. Defined as an array of volumeMount objects. | [] | | ||
| | `bytebase.extraVolumes` | Additional Bytebase volumes. Defined as an array of volume objects. | [] | | ||
| | `httpRoute.enabled` | Enable a Gateway API `HTTPRoute` for Bytebase. Mutually exclusive with Ingress, and requires a Gateway API implementation in the cluster. | false | |
There was a problem hiding this comment.
Same as the values.yaml comment: "Mutually exclusive with Ingress" is inaccurate — the chart has no Ingress to conflict with. Suggest: "Enable a Gateway API HTTPRoute to expose Bytebase, instead of an externally-managed Ingress/LoadBalancer. Requires a Gateway API implementation in the cluster."



Summary
Adds an opt-in Gateway API
HTTPRoutetemplate to the Bytebase Helm chart, so clusters using a Gateway APIimplementation (instead of an Ingress controller) can expose Bytebase natively. Follows the pattern used by other
charts such as
argoproj/argo-helm.What changed
httpRoutevalues block (top-level), mutually exclusive withingress:to the bytebase-entrypoint Service on port 80. Callers needing path splitting/header filters set httpRoute.rules
explicitly.
Backward compatibility
Fully backward compatible — httpRoute.enabled defaults to false; existing installs are unaffected.
Testing
helm template renders correctly with httpRoute.enabled=true (catch-all and explicit-rules cases) and disabled.