feat(console): wire list_service_accounts into New Fleet's k8s field group (studio#104) - #109
Open
brettchien wants to merge 1 commit into
Conversation
…group (studio#104) Fifth sub-item of #104, stacked on #108. Service account (optional) becomes a <select> (was plain text) populated from list_service_accounts(context, namespace) — unlike namespace, a service account must already exist for k8s to accept it as a pod's serviceAccountName, so (unlike namespace's <input>+ <datalist>) a plain select with no free-text escape hatch is the right shape here, matching context's treatment. Reload triggers: context change (cascades into namespace + service-account reload) and namespace field's "change" event (fires on blur/commit, not per keystroke — avoids a tool call per character typed). Per #104's design this tool's failures are deliberately silent — unlike list_k8s_contexts/list_namespaces (which show a status message on failure), any error here, including an RBAC-denied list (common against a scoped-down cluster identity), just falls back to the "namespace default" option with no status shown. The field is optional and the whole point of default-SA fallback is that it's fine not to have a definitive answer here. Verified locally: npm run typecheck clean, npm test 102/102, npm run build succeeds. Ref: studio#104.
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
Fifth sub-item of #104, stacked on #108 (→ #107 → #106 → #105, merge in order). Wires
list_service_accountsinto the k8s field group added in #108 — "Service account (optional)" goes from a plain text input to a<select>populated from the currently selected context + namespace.<select>, not<input>+<datalist>(unlike namespace): a service account must already exist for k8s to accept it as a pod'sserviceAccountName— there's no "type a brand-new one" case the way there is for namespace (which the deploy flow can bring into existence). So no free-text escape hatch here, matching howcontextis treated.change(cascades into reloading both namespace suggestions and the service-account list) and the namespace field'schangeevent — deliberatelychange(fires on blur/commit), notinput(every keystroke), to avoid a tool call per character typed.list, which is common against a scoped-down cluster identity — falls back to the "— namespace default —" option with no status message shown. This is different fromlist_k8s_contexts/list_namespaces(feat(console): provider picker + k8s context/namespace fields in New Fleet wizard (studio#104) #108), which do show a status on failure. The field is optional and the whole contract of "default SA fallback" is that not having a definitive answer here is fine.Testing
npm run typecheckclean,npm test102/102 passing,npm run buildsucceeds — same as #108, no OOM constraint on this side of the repo.Scope note
fleetsK8sToml.ts(client-side write helper forfleets-k8s.toml) and thedeploy_provision/K8sDriverdispatch design question are still open in #104.Ref #104. Stacks on #108 (→ #107 → #106 → #105) — merge in order.