Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Support multiple ordered sandbox pools per installation

Aberta
  • Algo errado?
#397 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
20/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
go, postgresql
Domínio
backend-api-design, databases, infrastructure

Direção de pesquisa

Start with services/core/internal/deployment/placement/placement.go and the contracts/agents-api/sandbox-deployment.md contract, then trace the runtime_deployment schema and deployment API. The proposal spans placement, lifecycle, API, client validators, and Web, with open design questions still unresolved. Done means ordered pools replace the singleton across these areas while preserving the stated placement and restore constraints.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Problem

An installation can select exactly one Sandbox Provider (docker, microsandbox or e2b). Administrators cannot combine compute sources, for example Docker nodes plus microsandbox nodes, or self-hosted nodes that overflow to E2B. Switching providers requires a full sandbox reset that clears all hosted resources.

Multiple nodes of the same provider already work: DecidePlacement picks an online, ready node with free capacity, preferring the highest ready generation and then the fewest active sandboxes.

Where the single-provider assumption lives

  • Contract: contracts/agents-api/sandbox-deployment.md says PostgreSQL holds "one active selection per installation", provider is "exactly one of docker, microsandbox, e2b", and changing to a different backend requires a reset first.
  • Schema: runtime_deployment is a singleton table (singleton boolean PRIMARY KEY CHECK (singleton)) holding one provider_kind, mode, generation and specification. runtime_deployment_generations keeps retained generations only so that existing allocations can still be cleaned up.
  • Placement: services/core/internal/deployment/placement/placement.go returns no placement in direct mode and otherwise chooses among the nodes of the single provider.
  • Node configuration: providers.Load rejects configuring both docker and microsandbox ("only one sandbox provider can be configured").
  • API and Web: /core/v1/sandbox/deployment GET/POST/PUT take one selection object, and SandboxSetupWizard asks the administrator to pick one provider.

Proposal

Replace the singleton deployment with an ordered list of sandbox pools. Each pool has its own provider, specification, Runtime release, generation, credential and priority.

  • Data model: pools replace the runtime_deployment singleton. Placements and allocations record their pool, including direct (E2B) allocations, which have no placement record today.
  • Placement: try pools in priority order and use the first one with admissible capacity. Within a node pool, keep the current node selection rules. Direct pools need a declared capacity limit so that lower-priority pools can be reached.
  • Lifecycle: generation rollout, reset, owner epoch, suspension policy and node enrollment become per-pool. Removing or replacing a pool clears only that pool's resources.
  • API and contract: replace the single deployment object with pool CRUD and ordering under /core/v1/sandbox/. Update the OpenAPI, sandbox-deployment.md and its zh translation, and the @oac/agents-client validators.
  • Web: show a pool list with add, reorder, and per-pool nodes and capacity.

Constraints

  • Ordering applies only when a new Session is placed, based on capacity and availability. A failed or unknown Create is never retried in another pool: the Sandbox Provider contract forbids replaying Create, and Core never substitutes another implementation.
  • An existing placement, allocation or suspended Environment stays in its original pool and node. Restores never move to another pool.
  • No provider-name branches in placement or lifecycle code. Pool behavior comes from the registered adapter declarations.
  • Pre-release: replace the singleton outright, with no compatibility layer for the old single-deployment API.

Open questions

  • Should a pool's capacity limit be declared by the adapter, set by the administrator, or both?
  • Can pools of the same provider kind coexist, for example two E2B pools with different templates?
  • How should Session-level selection (for example, by resources or Harness) interact with pool order, if at all?
Linguagem predominante
Go
Estrelas
182
Forks
17
Merge médio
1h 15min
PRs com merge (30d)
360

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de MiniMax-AI/OpenAgentCore

Todas as issues de MiniMax-AI/OpenAgentCore

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.