Skip to content

feat(helm): add Gateway API HTTPRoute support#20561

Open
roulettedares wants to merge 3 commits into
bytebase:mainfrom
roulettedares:feature/httproute
Open

feat(helm): add Gateway API HTTPRoute support#20561
roulettedares wants to merge 3 commits into
bytebase:mainfrom
roulettedares:feature/httproute

Conversation

@roulettedares

@roulettedares roulettedares commented Jun 10, 2026

Copy link
Copy Markdown

Summary

Adds an opt-in Gateway API HTTPRoute template to the Bytebase Helm chart, so clusters using a Gateway API
implementation (instead of an Ingress controller) can expose Bytebase natively. Follows the pattern used by other
charts such as argoproj/argo-helm.

What changed

  • New httpRoute values block (top-level), mutually exclusive with ingress:
httpRoute:
  enabled: false          # opt-in
  annotations: {}
  parentRefs: []          # Gateway API parentRefs; must reference an existing Gateway
  hostnames: []           # hostnames to match
  rules: []               # custom rules; defaults to a catch-all if unset
  • When httpRoute.rules is empty, the template emits a single catch-all rule (PathPrefix /) whose backendRef is wired
    to the bytebase-entrypoint Service on port 80. Callers needing path splitting/header filters set httpRoute.rules
    explicitly.
  • Chart README.md Parameters table documents the new values.

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.

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
@roulettedares roulettedares requested a review from a team as a code owner June 10, 2026 01:19
@cla-bot

cla-bot Bot commented Jun 10, 2026

Copy link
Copy Markdown

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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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 }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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.
@cla-bot

cla-bot Bot commented Jun 10, 2026

Copy link
Copy Markdown

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.

@sonarqubecloud

Copy link
Copy Markdown

@d-bytebase d-bytebase left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.md and values.yaml is inaccurate (see inline comments).

Optional

  • Chart.yaml is still at 1.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: 1 on a single backendRef is 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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 |

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants