[HYPERSHELL-76] feat(gateway): gate Running phase on Gateway route readiness - #131
Open
jsell-rh wants to merge 7 commits into
Open
[HYPERSHELL-76] feat(gateway): gate Running phase on Gateway route readiness#131jsell-rh wants to merge 7 commits into
jsell-rh wants to merge 7 commits into
Conversation
… port A routed gateway is currently reported Running (and its connect command surfaced) as soon as its Deployment is Ready, ignoring whether the underlying Gateway API Gateway is Programmed with an assigned address. Users get a command pointing at an endpoint that is not yet routable. Refine the health and routing specs so that: - Running for a routed gateway additionally requires its external exposure to be observed Ready (Gateway API adapter: Programmed=True + non-empty .status.addresses); otherwise phase stays Provisioning, then Degraded after a grace window (GATEWAY_ROUTE_READY_TIMEOUT, default 10m). - The console/CLI surface the connection command as ready only at phase Running. - Address resolution and readiness observation live behind an application-owned Gateway Exposure port, with the Gateway API implementation as one adapter and OpenShift Route / passthrough Route adapters expected to plug in unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Introduce a Gateway Exposure port (internal/exposure) with a Gateway API adapter that both resolves the external route address and observes route readiness (Programmed=True with an assigned address). Wire the port into the provisioning reconciler and the health reconciler so a routed gateway stays Provisioning until its underlying Gateway is programmed and routable, moving to Degraded only after a configurable grace window (GATEWAY_ROUTE_READY_TIMEOUT, default 10m). A gateway that reaches Running and later loses readiness is marked Degraded immediately. The port/adapter boundary keeps address resolution and readiness observation behind an application-owned interface so additional exposure backends (routes, passthrough routes) can be added without touching the reconcilers. Implements specs/platform/openshell-gateway-health.spec.md and openshell-gateway-routing.spec.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…nning The gateway detail Connection tab and the row-action "Copy CLI connection command" previously appeared as soon as an endpoint (route address) was published. Because the route address is derived and published before the underlying Gateway is programmed and routable, this handed users a command targeting an endpoint that was not yet reachable. Add isGatewayReadyToConnect (phase === "Running" AND endpoint present) and route the connection command through it: carry `phase` onto GatewayConnection, gate buildGatewayAddCommand (which both the detail header and row action use) and the login step. While provisioning, the login step now shows a provisioning affordance instead of the command. Implements the "Connection Command Surfaced Only When Ready" requirement in specs/platform/openshell-gateway-health.spec.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The provisioning poll reused the access token acquired before the loop.
Gateway provisioning can outlast the token lifetime, after which every
api_curl got a 401 and the phase read back empty ("unknown"), so the
poll timed out even though the gateway had reached Running. Re-acquire
the token each iteration; api_curl reads _OIDC_ACCESS_TOKEN per call.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…into feat/gateway-route-readiness # Conflicts: # components/control-plane/internal/gateway/reconciler.go # specs/platform/openshell-gateway-routing.spec.md
jsell-rh
changed the title
…essage The connectionLoginUnavailable message copy changed but the extracted locale bundle was not regenerated, so the web-console i18n:check gate (cmp of locales/en.json against a fresh formatjs extract) failed in CI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The connection command now surfaces only when a gateway's phase is "Running" (isGatewayReadyToConnect), so the shared gateway fixture must report Running for the connection-command journeys, and the login-step pending assertion must use the new "still provisioning" message. Also await the details-page h1 before the axe scan to deflake the unknown- status theme check. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A gateway was reported Running (and its OpenShell connect command surfaced) as soon as its Deployment was ready — before the underlying Gateway API resource was actually
Programmed=Truewith an assigned address. Users could copy a connect command that pointed at an endpoint the mesh could not yet route to.This branch gates the
Runningphase on route readiness: the gateway staysProvisioninguntil the Gateway that fronts its route is observedProgrammed=Truewith an address, then transitions toRunning. If it never programs, it staysProvisioningand degrades after a grace window (GATEWAY_ROUTE_READY_TIMEOUT, default 10m).Implements spec
4c92205(specs/platform/openshell-gateway-health.spec.md).Changes
46e926b): Gateway Exposure port + Gateway API adapter (hexagonal). The route address may be published before readiness; the health reconciler promotesProvisioning -> Runningonly after observingProgrammed=True+ address, and-> Degradedafter the route-ready timeout. Reads status via typedsigs.k8s.io/gateway-api. Correctly handles the shared-Gateway topology (one shared Gateway + per-tenant GRPCRoute).837520f): centralize the connect gate throughisGatewayReadyToConnect(phase === "Running"AND endpoint present).route_addressmay be present before readiness, so the CLI command and login step are withheld until Running; a provisioning affordance is shown instead.a7c1019): refresh the OIDC token inside the provisioning poll — provisioning can outlast the token lifetime, which previously caused a false timeout.Testing
gateway-management-uiunit tests cover the readiness gate (isGatewayReadyToConnect,buildGatewayAddCommand, connection-steps, page-level withholding).Provisioningwhileawaiting route readiness, publishesroute_addressbefore readiness, then promotes toRunning (Healthy)only after the fronting Gateway isProgrammed=Truewith an address; the API then returnsphase=Running+route_address, the OpenShell CLI connects, and a sandbox is created and exec'd into.🤖 Generated with Claude Code