feat(studio-cp,oab-mcp): list_aws_profiles / list_k8s_contexts tools (studio#104) - #105
Open
brettchien wants to merge 1 commit into
Open
feat(studio-cp,oab-mcp): list_aws_profiles / list_k8s_contexts tools (studio#104)#105brettchien wants to merge 1 commit into
brettchien wants to merge 1 commit into
Conversation
…(studio#104) Backs the "+ New fleet" console wizard's provider-specific <select> fields (k8s onboarding UX, follow-up to #97's driver backend). Both are read-only, run as a local sidecar next to the console (src-tauri/src/mcp.rs), so they read the operator's own machine: - list_aws_profiles: hand-rolled ~/.aws/config + ~/.aws/credentials scan (name + region). Not aws-config's internal profile-file parser, which isn't a stable public surface — same "pure, easy to unit-test" spirit as fleetToml.ts's client-side TOML edits. - list_k8s_contexts: kube::config::Kubeconfig::read(), same API observe_k8s_identity/K8sDriver::from_context already use. Both distinguish exists=false (nothing configured — console should show setup guidance: aws configure/sso login, or install OrbStack/kind/minikube) from error=Some(..) (a config was found but couldn't be read/parsed — show the raw error). Neither blocks: the console falls back to a free-text field either way. Ref: studio#104 (k8s console onboarding UX, follow-up to #97).
This was referenced Aug 27, 2026
Open
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
First sub-item of #104 (k8s console onboarding UX, follow-up to #97's now-merged driver backend): two new read-only MCP tools,
list_aws_profilesandlist_k8s_contexts. These back the "+ New fleet" wizard's provider-specific<select>fields — right now that form is AWS-only free-text (Region/Profile/Principal); the k8s onboarding design (thread discussion linked in #104) calls for<select>s populated from what's actually on the operator's machine, not free text.list_aws_profiles— scans~/.aws/config(+~/.aws/credentialsfor credentials-only profiles) for profile names and region. Hand-rolled parser, notaws-config's internal profile-file machinery (not a stable public surface) — same "pure, line-based, easy to unit-test" spirit asfleetToml.ts's client-side TOML edits.list_k8s_contexts—kube::config::Kubeconfig::read(), the same callobserve_k8s_identity/K8sDriver::from_contextalready use. Returns context name/cluster/namespace/user + which iscurrent-context.Both are local reads:
oab-mcpruns as a Tauri sidecar child process next to the console (src-tauri/src/mcp.rs), so these read the operator's own machine, not a remote server — the guidance behavior below is only meaningful because of that.exists/error— two different failure shapes, not one generic errorexists=false— nothing configured at all (no~/.aws/config, no kubeconfig). The console should show actionable guidance (aws configure/aws sso login; or install OrbStack/kind/minikube, or merge in a cloud kubeconfig) — this isn't an error state, it's "you haven't set this up yet."error=Some(...)— a config file exists but couldn't be read/parsed. Show the raw error, don't guess.Testing
Added unit tests for the pure parsing functions (
parse_aws_config,parse_aws_credentials_names) covering default/named profiles, region extraction, comment/blank-line handling, and empty input.Local build/test could not complete —
cargo build/cargo check -p studio-cp -p oab-mcpOOM-kills onaws-sdk-ec2/aws-sdk-s3(pulled in transitively viaoabctl) on this machine regardless of-j 1orcodegen-units=1, the same pre-existing "small boxes' RAM" constraint noted in this repo's CI config and hit repeatedly during #97's development (see #98's PR description). I hand-verified thekube-client 0.99.0API surface I use (Kubeconfig/NamedContext/Contextfield types, incl. catching thatContext.userisOption<String>notString) directly against the vendored crate source rather than guessing. CI (build-test) is the real gate here — flagging explicitly rather than asserting it compiles from local confidence alone.Scope note
Doesn't touch
list_namespaces/list_service_accounts(both need a context+namespace already chosen — separate, dependent sub-item) or the console-side wiring (fillOptions-style<select>population) — tracked separately in #104.Ref #104.