Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Support multiple ordered sandbox pools per installation

Offen
  • Stimmt etwas nicht?
#397 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
go, postgresql
Bereich
backend-api-design, databases, infrastructure

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?
Vorherrschende Sprache
Go
Sterne
182
Forks
17
Ø Merge
1 Std. 15 Min.
Gemergte PRs (30 T.)
360

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus MiniMax-AI/OpenAgentCore

Alle Issues in MiniMax-AI/OpenAgentCore

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.