feat(console): provider picker + k8s context/namespace fields in New Fleet wizard (studio#104) - #108
Open
brettchien wants to merge 1 commit into
Conversation
…Fleet wizard (studio#104) Fourth sub-item of #104, stacked on #107. Adds the console-side UI half of the k8s onboarding design — the "+ New fleet" identity form (previously AWS-only: Region/Credential profile/Principal) now starts with a Provider select (AWS / Kubernetes), toggling between the existing AWS field group and a new k8s group: - Context: <select>, populated live from the new list_k8s_contexts tool (#105), current-context flagged in the label. - Namespace: text input + <datalist> from list_namespaces (#106), scoped to whichever context is selected — deliberately NOT a plain <select>, since a brand-new namespace is a valid choice per #104's design and a select can't express "not in this list yet". - Service account (optional): plain text input for now (list_service_accounts wiring is a smaller follow-up; per #104's design any failure there should silently fall back to the namespace's default SA anyway, so a live <select> buys less than it does for context/namespace). **k8s submission is intentionally blocked, not wired through**: the identity form's submit handler shows "Kubernetes provisioning isn't available yet — tracked in #104" and refuses to advance to the Compose step when provider=k8s. This is deliberate, not a placeholder oversight — traced deploy_provision's call chain this same session and found it requires an already-stored manifest (K8sDriver::apply doesn't persist one the way ECS's apply_manifests does), so wiring k8s all the way to a live deploy_provision call would either silently fail or need the driver-dispatch design question resolved first (posted to #104, unresolved as of this commit). Shipping the picker/discovery UI now is still real progress — AWS path is 100% unchanged, and this is testable/mergeable independent of how the deploy_provision question resolves. Verified locally (no OOM constraint here — TS/vite, not cargo): `npm run typecheck` clean, `npm test` 102/102 passing, `npm run build` succeeds. Ref: studio#104.
This was referenced Aug 27, 2026
brettchien
added a commit
that referenced
this pull request
Aug 27, 2026
…104) t_provision now branches on a new provider arg (default "aws", unchanged behavior): "k8s" calls provision_from_library_k8s (#114) with context/ expected_principal taken as direct args, not resolved via a fleet name — the console's identity form already collects context/namespace/service- account directly (#108/#109), and for a brand-new fleet there's no existing K8sFleetBinding to look up anyway. Fleet-scoped k8s lookup (for redeploying into an already-known k8s fleet) is left as explicit future work, not needed for this dispatch to exist. Also updates deploy_provision's tool description, which was stale after #113 (redeploy no longer requires an existing manifest) and needed the new provider/context/expected_principal params documented. NOTE — branch lineage: this stack (#112→#113→#114→this) was cut from `main` before #104's original stack (#105-110) merged, not from #110 — so K8sFleetBinding.expected_principal (originally #107) is re-added here too. Identical field in both places; trivial merge conflict to resolve whenever both land, flagging explicitly rather than silently duplicating without a note. With this, deploy_provision fully supports k8s end-to-end (provisioning side) — the remaining piece for full onboarding is unblocking console's k8s "Next" button (#108/#109's placeholder), a separate follow-up. Ref: studio#104.
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
Fourth sub-item of #104, stacked on #107 → #106 → #105 (merge in order). Console-side UI: the "+ New fleet" identity form gains a Provider picker (AWS / Kubernetes) and a k8s field group, backed by the
list_k8s_contexts/list_namespacestools from #105/#106.<select>, defaults to AWS (unchanged today's default). Switching toggles which field group is visible;identityForm.reset()(already called on every open/close) naturally resets it back to AWS.<select>, populated fromlist_k8s_contexts. Whichever matchescurrent_contextis labeled(current).<datalist>fromlist_namespaces(context), re-populated on context change. Deliberately not a<select>: per K8s fleet onboarding — console UX for provider selection ('+ New fleet') #104's design a brand-new namespace is a valid entry (this tool can only list what already exists), and a plain select can't express "type something not in this list."list_service_accountsyet — smaller, clearly-separable follow-up; per the design, any failure there should silently fall back to the namespace'sdefaultSA anyway, so the live-select payoff is smaller here than for context/namespace (where a typo is much more likely/costly).Why k8s submission is blocked, not wired through
Traced
deploy_provision's actual call chain earlier this session (posted to #104):redeploy()requires an already-stored manifest to patch — it can't create one from scratch.K8sDriver::apply(already merged, #99) is a fully independent implementation that doesn't persist a manifest anywhere, so swapping it in forEcsDriverwouldn't give k8s parity with the AWS "+ New fleet" flow — it'd need the driver-dispatch design question resolved first (still open, unresolved as of this PR).Rather than wire the k8s path through to a
deploy_provisioncall that would either silently misbehave or need to guess at an unresolved design, the identity form's submit handler explicitly blocks progressing past step 1 whenprovider=k8s:This is deliberate scoping, not a placeholder left by accident — shipping the discovery/picker UI now is still real, independently useful progress (and unblocks review/testing of the
<select>/<datalist>population logic against #105/#106's tools), without pretending the end-to-end flow works when it doesn't yet.AWS path is 100% unchanged — same fields, same submit flow, same
deploy_provisioncall. This PR only adds a branch point.Testing
Verified locally — no OOM constraint here, this is TypeScript/Vite, not Cargo:
npm run typecheck— cleannpm test— 102/102 passing (no new tests added fordeploy.ts; it has no existing test file — DOM-wiring code, matches the file's existing untested-by-design precedent)npm run build— succeedsScope note
list_service_accountswiring and thedeploy_provisionprovider-dispatch question are tracked separately in #104.Ref #104. Stacks on #107 (→ #106 → #105) — merge in order.