Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Support multiple ordered sandbox pools per installation

Ouverte
  • Quelque chose ne va pas ?
#397 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
go, postgresql
Domaine
backend-api-design, databases, infrastructure

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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?
Langage dominant
Go
Étoiles
182
Forks
17
Merge moyen
1 h 15 min
PR mergées (30 j)
360

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MiniMax-AI/OpenAgentCore

Toutes les issues de MiniMax-AI/OpenAgentCore

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.