feat: add names for rules under maas api http route#655
feat: add names for rules under maas api http route#655nirrozenbaum wants to merge 1 commit intoopendatahub-io:mainfrom
Conversation
Signed-off-by: Nir Rozenbaum <nrozenba@redhat.com>
📝 WalkthroughWalkthroughA Kubernetes HTTPRoute configuration file was updated to add explicit Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
/cc @jland-redhat |
nirrozenbaum
changed the title
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jland-redhat, nirrozenbaum The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/override ci/prow/e2e-test-maas |
|
@jland-redhat: Overrode contexts on behalf of jland-redhat: ci/prow/e2e-test-maas DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deployment/base/maas-api/networking/httproute.yaml`:
- Around line 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.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: d45a9b5f-6eca-4df5-9d2c-33c8be708d76
📒 Files selected for processing (1)
deployment/base/maas-api/networking/httproute.yaml
| - name: maas-v1-models | ||
| matches: |
There was a problem hiding this comment.
🧩 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.nameusage. [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[].namemay 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.namebehavior; 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 5Repository: 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 -40Repository: 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.yamlRepository: 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.
|
/retest |
|
/hold tried to update this manually in demo-2 cluster and it didn't work. |
|
@nirrozenbaum: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
2 participants
Description
add name to the http route rules of maas api.
this might be helpful in the integration with payload processing, for instruction payload processing ext proc to skip if the request matches one of these rules.
no logic/behavior change to maas.
How Has This Been Tested?
Merge criteria:
Summary by CodeRabbit