Skip to content

feat: add names for rules under maas api http route #655

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nirrozenbaum wants to merge 1 commit into
base: main
Choose a base branch
from
+4 −2
Open

feat: add names for rules under maas api http route #655

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions deployment/base/maas-api/networking/httproute.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,8 @@ spec:
namespace: openshift-ingress
rules:
# OpenAI-compatible /v1/models endpoint at top level
- matches:
- name: maas-v1-models
matches:
Comment on lines +11 to +12
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot Mar 31, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

For Kubernetes Gateway API, in which versions is HTTPRoute.spec.rules[].name supported in gateway.networking.k8s.io/v1, and are there controller compatibility caveats (e.g., Envoy Gateway, Istio, Kong, OpenShift ingress implementations)?

💡 Result:

When is HTTPRoute.spec.rules[].name supported in gateway.networking.k8s.io/v1?

HTTPRoute.spec.rules[].name (a Name field on HTTPRouteRule) is available starting with Kubernetes Gateway API v1.4.0 (Standard channel) and therefore is present in the gateway.networking.k8s.io/v1 CRDs for v1.4.0+. It is not in the v1.0–v1.3 v1 CRDs. [1]

This comes from GEP-995 (Named route rules), which added an optional name field to route-rule types (including HTTPRouteRule). [2]

Practical implication: the field will only round-trip (be stored) if your cluster has Gateway API CRDs >= v1.4.0 installed; otherwise it will be rejected/pruned by schema.

Controller compatibility caveats (Envoy Gateway / Istio / Kong / OpenShift)

Envoy Gateway

  • Envoy Gateway versions compiled against Gateway API v1.4.x will understand the field (schema-wise). The Envoy Gateway compatibility matrix shows when it moved from Gateway API v1.3.0 to v1.4.0+ (e.g., EG v1.6 uses Gateway API v1.4.0; EG v1.7 uses v1.4.1). [3]
  • Envoy Gateway docs also document HTTPRouteRule.name usage. [4]

Istio

  • Istio is listed in the Gateway API v1.4 implementations/conformance page, indicating active v1.4 tracking/testing. [5]
  • As with most implementations, having the field in the CRD does not guarantee Istio uses it for any behavior unless a specific Istio feature/policy references rule names; treat it as potentially metadata-only unless you confirm otherwise in your Istio version.

Kong (KIC / Kong Operator)

  • Kong Operator documentation shows Gateway API compatibility only up through Gateway API v1.3.x (not v1.4), which means v1.4-only fields like spec.rules[].name may not be supported in the bundled/expected Gateway API version for that product line/version. [6]
  • Also, the Gateway API v1.4 implementations page shows Kong Operator entries but does not imply feature-level support for named rules. [5]

OpenShift ingress / OpenShift Gateway API implementation

  • OpenShift’s Gateway API docs show it provisions a Gateway API implementation (tied to OpenShift Service Mesh components) and includes platform-specific operational constraints (namespaces, provisioning behavior, and noted conflicts). [7]
  • Rule naming support still ultimately depends on which Gateway API CRD version OpenShift installs/expects (i.e., whether it’s v1.4.0+). OpenShift docs don’t clearly call out HTTPRouteRule.name behavior; assume it’s accepted if the CRD is v1.4+ but may be ignored by the controller unless explicitly implemented.

Sources

[1] Kubernetes Gateway API GitHub releases – v1.4.0 notes (adds Name field to HTTPRouteRule)
[2] GEP-995: Named route rules
[3] Envoy Gateway compatibility matrix (Gateway API version per EG release)
[4] Envoy Gateway HTTPRoute API docs (documents name field on rules)
[5] Gateway API implementations/conformance page for v1.4
[6] Kong Operator version compatibility (Gateway API versions listed through v1.3.x)
[7] OKD/OpenShift Gateway API documentation (implementation/provisioning constraints)

🏁 Script executed:

# Search for Gateway API version constraints and documentation
find . -type f \( -name "*.yaml" -o -name "*.yml" -o -name "*.md" -o -name "*.txt" \) | head -20

# Look for any CRD definitions or version pinning
rg -i "gateway.*api.*version|gateway\.networking\.k8s\.io" --type yaml | head -30

# Check for deployment docs or README
fd -i readme . --max-results 5

Repository: opendatahub-io/models-as-a-service

Length of output: 2579

🏁 Script executed:

# Search for any Gateway API controller version requirements
rg -i "envoy|istio|kong|gateway" deployment/ --type yaml -A 2 -B 2 | head -50

# Check if there are any kustomization or deployment documentation
find deployment/ -type f \( -name "*.md" -o -name "README*" -o -name "requirements*" \) -exec cat {} \;

# Look for CRD versions and schema specifications
rg "apiVersion.*gateway\.networking" . --type yaml -B 2 -A 5 | head -40

Repository: opendatahub-io/models-as-a-service

Length of output: 15731

🏁 Script executed:

# Check for version constraints in config, docs, or setup files
find . -maxdepth 3 -type f \( -name "*.md" -o -name "requirements.txt" -o -name "Dockerfile*" -o -name "Chart.yaml" \) -exec grep -l "gateway\|gateway-api" {} \;

# Look for the actual HTTPRoute file to see context
cat deployment/base/maas-api/networking/httproute.yaml

Repository: opendatahub-io/models-as-a-service

Length of output: 1169

Document minimum Gateway API version requirement (v1.4.0+) for HTTPRoute.spec.rules[].name field.

rules[].name is only supported in Gateway API v1.4.0+; earlier CRD versions will reject this field during schema validation. This is an architectural compatibility issue with no minimum version constraint documented in the deployment config or README. Verify the deployment is targeting OpenShift 4.18+ (or equivalent cluster Gateway API version) and add explicit documentation of this requirement.

Also applies to: lines 21-22 (second rule name: maas-api)

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@deployment/base/maas-api/networking/httproute.yaml` around lines 11 - 12, The
HTTPRoute uses rules[].name which is only supported in Gateway API v1.4.0+, so
update the deployment docs and the manifest to declare that minimum requirement:
add a note in the README (or deployment README) and add an inline
comment/annotation in the HTTPRoute manifest near HTTPRoute.spec.rules[].name
(both occurrences `name: maas-v1-models` and `name: maas-api`) stating "Requires
Gateway API v1.4.0+ (OpenShift 4.18+ or equivalent)"; ensure any CI/validation
or deployment instructions mention verifying cluster Gateway API version before
applying the CRD.

- path:
type: PathPrefix
value: /v1/models
Expand All @@ -17,7 +18,8 @@ spec:
port: 8080
weight: 100
# All other maas-api endpoints remain under /maas-api prefix
- matches:
- name: maas-api
matches:
- path:
type: PathPrefix
value: /maas-api
Expand Down
Loading