Skip to content

feat(studio-cp,oab-mcp): list_namespaces / list_service_accounts tools (studio#104) - #106

Open
brettchien wants to merge 1 commit into
feat/k8s-onboarding-list-toolsfrom
feat/k8s-onboarding-namespace-sa-tools
Open

feat(studio-cp,oab-mcp): list_namespaces / list_service_accounts tools (studio#104)#106
brettchien wants to merge 1 commit into
feat/k8s-onboarding-list-toolsfrom
feat/k8s-onboarding-namespace-sa-tools

Conversation

@brettchien

Copy link
Copy Markdown
Contributor

Summary

Second sub-item of #104, stacked on #105 (list_aws_profiles/list_k8s_contexts — same tools() vec, same design). Two context-scoped k8s discovery tools:

  • list_namespaces(context?)Api<Namespace>::list() against the given (or current-context) kubeconfig context. Backs the New Fleet wizard's namespace <select>. A manual-entry fallback still covers a namespace that doesn't exist yet — this can only list what's already there.
  • list_service_accounts(context?, namespace)Api<ServiceAccount>::list(namespace). Backs the optional service-account <select>. Per the design decided in the K8s fleet onboarding — console UX for provider selection ('+ New fleet') #104 thread discussion: any failure here (including an RBAC-denied list, which is common against a scoped-down cluster identity) should read to the caller as "leave it unset" — the namespace's default service account applies — not surfaced as an error. So unlike list_aws_profiles/list_k8s_contexts, this one doesn't split exists/error; it just errors normally and the console is expected to swallow it.

Also factored the from_kubeconfig + Client::try_from boilerplate observe_k8s_identity had inlined into a shared k8s_client_for() helper, used by both new functions and refactored into observe_k8s_identity too — same logic, no behavior change there.

Verification

Same situation as #105: local cargo check -p studio-cp -p oab-mcp OOM-kills on aws-sdk-ec2 on this machine regardless of retries (5 attempts total across both PRs today, all the same failure) — pre-existing environment constraint, not something this change causes. Hand-verified the k8s-openapi 0.24/kube-client 0.99 API surface directly against vendored crate source: Namespace/ServiceAccount shape (metadata: ObjectMeta, .metadata.name: Option<String>), Api::namespaced(client, ns: &str), Api::list(&ListParams) -> Result<ObjectList<K>> with ObjectList.items: Vec<K>, ListParams: Default. CI is the real gate — same disclosure as #105.

Scope note

Console-side wiring (<select> population, provider picker) and the remaining backend items (k8s_fleet_config_write, deploy_provision provider param, K8sFleetBinding.expected_principal) are tracked separately in #104.

Ref #104. Stacks on #105 — please merge #105 first.

…s (studio#104)

Second sub-item of #104 (stacked on #105's list_aws_profiles/list_k8s_contexts,
same tools() vec / same design). Both are context-scoped k8s discovery:

- list_namespaces(context?): Api<Namespace>::list() for the given/current
  kubeconfig context. Backs the New Fleet wizard's namespace <select> — a
  manual-entry fallback covers a brand-new namespace that doesn't exist yet.
- list_service_accounts(context?, namespace): Api<ServiceAccount>::
  list(namespace). Backs the optional service-account <select>. Per the
  design, any failure here (including an RBAC-denied list, which is common
  against a restricted-scope cluster identity) should read to the caller as
  "leave it unset" (the namespace's default service account applies), not
  as an error to surface — so unlike list_aws_profiles/list_k8s_contexts
  this one doesn't split exists/error, it just errors normally.

Same k8s_client_for() helper factors out the from_kubeconfig+Client::try_from
boilerplate observe_k8s_identity already had inlined.

Ref: studio#104.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant