Repository navigation
feat(helm): support agentgateway ingress #2469
Description
Activity
📋 triage-agent
Triage Assessment
Classification: feature-valid
Summary
Agentgateway support is feasible without bundling its controller, and the shared-Gateway design keeps the OpenShell chart controller-neutral.
Investigation
The chart renders portable
GatewayandGRPCRouteresources, but defaults and documentation are Envoy-specific.templates/grpcroute.yamlhas no parentsectionName. Agentgateway provisions a proxy Service for each Gateway using the Gateway name, so a chart-created Gateway namedopenshellcan collide with OpenShell’s existing Service. Closed #2097 and open PR #2108 address different controller/TLS concerns and do not provide this integration.Recommendation
Keep the issue open. Use a shared Gateway as the production path, require a non-conflicting name for chart-created development Gateways, and validate CLI plus sandbox operations through
test:e2e-kubernetes./assign
🏗️ build-plan
Implementation Plan
Issue type:
fix
Complexity: Low
Confidence: HighSummary
Make the existing Gateway API integration friendlier to arbitrary
GatewayClassimplementations without changing existing release behavior or
adding controller-specific support or CI. Use agentgateway as a manual
interoperability check.Scope
- Preserve
<fullname>as the default chart-created Gateway name. - Preserve explicit Gateway names unchanged.
- Use the same effective Gateway name in the generated Gateway and GRPCRoute.
- Document and test an explicit distinct name for controllers whose proxy
Service would otherwise conflict with the OpenShell Service. - Add an optional listener
sectionNamefor bring-your-own Gateways. - Generalize Helm comments and ingress documentation around GatewayClass
overrides and externally managed Gateways. - Resolve the effective Gateway name dynamically in the Envoy E2E wrapper.
Verification
mise run helm:testmise run helm:lintmise run helm:docs:check- Render checks for chart-owned and bring-your-own Gateway configurations.
- Envoy HA E2E provisioning and proxy discovery.
- Manual plaintext smoke test with an agentgateway GatewayClass on a local
Kubernetes cluster.
Out of Scope
- Agentgateway-specific Helm overlays, setup tasks, CI jobs, or support claims.
- TLS, BackendTLSPolicy, ListenerSet, HA, or controller policy resources.
- Installing or managing a Gateway API controller from the OpenShell chart.
Revision 7 — preserves existing Gateway identity and makes a distinct name an
explicit override, following maintainer feedback on PR #4345.- Preserve
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
@matthewgrossman when you have a moment, can you PTAL at this issue. I have been vouched, I reviewed the contrib guide, etc. and would like to work on this issue.
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
Follow-up issues discovered while validating agentgateway ingress:
- bug: SSH forwarding drops HTTPS behind TLS termination #3674 tracks the OpenShell SSH endpoint reconstruction bug exposed by frontend TLS termination. It currently blocks SSH-backed operations in the shared and dedicated frontend-TLS E2E paths when the OpenShell backend is plaintext.
- feat(e2e): preserve Kubernetes clusters for debugging #3675 tracks the opt-in Kubernetes E2E cluster and work-directory preservation used to inspect this class of failure after the wrapper exits.
Follow-up TODO:
- Add the dedicated agentgateway Gateway deployment mode after feat(helm): add agentgateway ingress support #3714 merges. The previously implemented code is preserved on the
danehans:3715-dedicated-agentgateway-gateway/danehansbranch and is tracked by feat(helm): support shared agentgateway Gateway #3715.
- Add the dedicated agentgateway Gateway deployment mode after feat(helm): add agentgateway ingress support #3714 merges. The previously implemented code is preserved on the
PR #3714 now uses the dedicated, chart-owned agentgateway topology to align with the existing Envoy Gateway integration and reduce the initial change. Shared Gateway support is follow-up work in #3715; the prototype is preserved at https://github.com/danehans/OpenShell/tree/3715-shared-agentgateway-gateway/danehans.
Hi @danehans , thanks for your interest in the project. I discussed this feature request with the team, and at this time this is not a feature we feel we need to support at this time. As it stands and based on the PRs submitted, using a custom GatewayClass with OpenShell is supported, as we currently demonstrate with Envoy Gateway in the helm chart.
From the problem statement above:
its generated proxy Service conflicts with OpenShell's Service when both use the chart's default name.
And from why it matters:
The naming conflict also makes a straightforward GatewayClass override fail.
We would accept a narrower scope of changes to address this issue specifically to allow smoother usage of GatewayClass override, but at this time we don't feel that it is needed to have a separate set of CI coverage to guarantee support for Agentgateway on its own. Our example using Envoy Gateway is such that it is a simple and common Gateway implementation available for use, and not necessarily to guarantee support for each Gateway implementation available.
- added a commit that references this issue
on Oct 9, 2026
User Story
As a Kubernetes operator using agentgateway, I want OpenShell to create a dedicated Gateway so that I can use agentgateway without deploying Envoy Gateway or maintaining separate ingress manifests.
Problem Statement
OpenShell documents and tests Envoy Gateway as its Kubernetes Gateway API implementation. Agentgateway is not covered by the chart or Kubernetes E2E suite, and its generated proxy Service conflicts with OpenShell's Service when both use the chart's default name.
Impact / Why This Matters
Agentgateway operators must maintain custom Gateway and GRPCRoute manifests and cannot rely on OpenShell's CI coverage. The naming conflict also makes a straightforward GatewayClass override fail.
Proposed Design
Keep the chart controller-neutral while supporting the existing chart-owned Gateway model with agentgateway.
openshell-ingress.Acceptance Criteria
Alternatives Considered
Agent Investigation
Revalidated against OpenShell main at
924486805, agentgateway v1.5.0, and Gateway API v1.6.2.Checklist