minds: bring-your-own cloud accounts (AWS / GCP / Azure)#2450
Open
minhtrinh-imbue wants to merge 15 commits into
Open
minds: bring-your-own cloud accounts (AWS / GCP / Azure)#2450minhtrinh-imbue wants to merge 15 commits into
minhtrinh-imbue wants to merge 15 commits into
Conversation
Adds a "cloud accounts" flow to the Minds create page: paste an IAM user's keys in a modal, mngr aws prepare runs as validation (rolled back on failure), and the account appears as a compute-provider option that creates go through. - mngr_aws/gcp/azure configs: optional pasted-credential fields (SecretStr, OVH/Vultr pattern) threaded into the SDK session with the ambient chain as unchanged fallback - bootstrap: byo-<backend>-<slug> provider block CRUD + alias sidecar; blocks survive the aws-* boot reconcile - api_v1: /desktop/cloud-accounts routes (list/create+prepare/rename/ delete with active-workspace guard); create accepts cloud_account - agent_creator: provider name short-circuit, prepare against the account block, region re-pin on create - Create.jinja: accounts modal (table, add form, prepare loader that blocks dismissal mid-flight) + BYO options in the compute dropdown Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds an instance-type select next to region, shown for AWS-backed selections (ambient + BYO accounts). Curated t3 shapes with a 4 GB floor (2 GB is documented to OOM the FCT build); t3.large stays the default. Threads as the existing --aws-instance-type build arg, so the provider block default applies when unset. Allowlist-validated at the create route. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Extends the cloud-accounts flow to gcp/azure, BYO-only (no ambient options): paste a service-account key JSON (GCP) or service-principal ids+secret (Azure) in the accounts modal, prepare runs as validation, and creates target the byo-<backend>-<slug> block. - LaunchMode.GCP/AZURE; skipped in the ambient compute dropdown - per-backend account blocks: gcp pins default_zone (GCE is zonal) + e2-standard-2; azure pins default_region + Standard_B2ms - generic run_mngr_provider_prepare (block-driven, --provider only); create re-pins zone/region then prepares - boot reconciler suppresses the credential-less default gcp/azure provider instances (same rationale as aws) - machine-size picker is now per-backend (t3/e2/B-series, 4GB floor); region machinery carries GCP zones and Azure regions - per-backend modal field groups + setup instructions Pairs with FCT branch minh/gcp-azure-create-templates ([create_templates.gcp/azure]). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A fresh subscription's first-ever Microsoft.Network registration routinely exceeds the old 180s cap (observed live); registration is one-time-per-subscription so the generous cap costs nothing later. Also sets expectations in the accounts-modal progress copy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Widens the shutdown-capable backend set (the one gate behind every Start/Stop surface) to the cloud-VM backends, whose providers support real VM-level stop/start (EC2 stop / GCE stop / Azure deallocate). For bring-your-own accounts, stopping is what halts the user's own billing; the provider state buckets keep stopped workspaces visible. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mngr observe reads settings.toml at launch, so a bring-your-own account block written at runtime is invisible to discovery until restart -- the new account's workspaces got no per-provider snapshots (no liveness, no Stop/Start controls). Bounce the supervisor on account create/delete, exactly as imbue_cloud signin/signout and the provider toggle already do. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two artifacts of transitions now taking 30-90s (cloud VMs) instead of ~2s (docker/lima): - suppress the "Server not responding" health badge while a row is STARTING/STOPPING -- unreachable-mid-transition is expected and the state badge already explains it - keep rendered rows sticky through the transition: a stopping VM transiently drops out of discovery (neither live-listable nor yet offline-reconstructed), and the rows-differ reload landed on the zero-workspace create form; disappearance-reloads are now skipped during lifecycle churn (pending action or 3-minute grace). Additions still reload immediately. Also snaps the accounts modal's mt-5 to the design-system spacing scale. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New pay-as-you-go subscriptions hit SkuNotAvailable on B-series in popular regions (observed live in westus). Add Dsv5/Dasv5 8/16GB alternates (different hardware pools) and reorder the region list to lead with the less-congested picks (eastus2 default). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Azure's scaffolding (RG/vnet/NSG) is region-locked, so region switching on an existing account was broken (vnet location conflict). One simple model instead: an Azure account entry is pinned to its region for life and gets its OWN resource group (byo-azure-<slug>-<region>); a different region = another entry with the same keys. The create form drops the Azure region picker (static pinned-region note instead) and never re-pins the block. Also widens the offering: AWS regions = full AMI-table set (adds eu-west-1, eu-central-1, ap-southeast-1, ap-northeast-1); GCP zones + Azure regions gain EU/APAC picks; capacity-alternate machine families (t3a/m6i for AWS, n2 for GCP) join the size pickers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A cloud VM's first stop mirrors the whole host_dir to the provider state store before deallocating (~10 min observed on Azure); the 300s cap killed the subprocess mid-flight and reported a false failure to the UI (row reverted to RUNNING + "Server not responding") while the real stop completed in the background. 1200s covers the slow path; docker/lima still finish in seconds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ponytail review: prepare_log was captured and returned but never read by the UI (the failure path already carries the output tail inside the error text), and aws_session_token had no modal input so no client could ever send it (the provider config field stays for settings.toml users). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
# Conflicts: # apps/minds/imbue/minds/bootstrap.py # apps/minds/imbue/minds/desktop_client/templates/pages/Create.jinja
…logs
From the multi-agent review triage (9 real findings of 32 candidates):
- BYO placement is pinned per account entry for ALL backends: the create
API resolves region from the account block and never re-pins (AWS/GCP
discovery clients are region/zone-bound, so a moved pin orphaned the
entry's existing workspaces); update_cloud_account_region deleted, the
create form shows the pin as a note for every BYO selection
- GCP/AZURE modes 400 early without a cloud account (previously failed
minutes later in the background thread)
- accounts-modal Rename uses an inline input (window.prompt throws in
Electron renderers)
- Electron stop path arms the landing transition guard (postMessage
bypassed it, resurrecting the reload-into-create-form flash)
- byo-<backend>-<slug> providers get friendly labels ("AWS (slug)")
- AwsProviderConfig rejects half-pasted credentials instead of silently
falling back to the ambient chain; GcpProviderConfig wraps unusable
(JSON-valid) keys in GcpCredentialsError
- required per-project changelog entries added (CI gate)
- import sorting + stale field docs
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All seven CI failures were compliance gates on the review-fix commit, no product-logic changes: - FakeAgentCreator.start_creation gains the new cloud_account / instance_type kwargs (the real signature grew; the stub 500'd) - explicit else on the per-mode prepare chain and the instance-type validation chain (if/elif ratchet) - logger.warning on both JSONDecodeError handlers (silent-catch ratchet) - ruff format pass on api_v1.py - typed rebind in list_cloud_account_providers (isinstance(x, dict) narrows to dict[object, object] under ty; 8 errors, one function) - regenerated mngr_aws / mngr_gcp READMEs (generated CLI docs embed the new provider-config fields) Co-Authored-By: Claude Fable 5 <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
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.
[Human-written]
UX flow:
Option in creation menu UI to configure your own AWS/GCP/Azure account

Clicking on "Configure," there is UI to view your onboarded cloud accounts and add new ones via key input, which will run


mngr prepareAccounts that have been successfully

mngr prepareed will be added to the list of compute providersAlso implemented/tested features: start/stop/restart/deletion of BYO cloud workspaces