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

feat(sdk): support create-time policy and complete resource results in Rust

Offen
  • Stimmt etwas nicht?
#3,646 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
api, backend

Rechercherichtung

The changes are in crates/openshell-sdk/src/types.rs. Start by reviewing the existing SandboxSpec and WorkspaceRef types to understand the missing fields. Examine the gRPC gateway's sandbox-create request and response structures to map the required identity, policy, and lifecycle metadata. Write tests to verify the new fields are correctly exposed in create/get results, preserving the ability to distinguish absent values from defaults.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

state:triage-needed
User Story

As a Rust SDK user building deployment automation, I want to create sandboxes with an explicit policy and inspect their stored configuration and lifecycle status through SDK calls. This requires policy on image-based creation and complete resource details in create/get results.

Problem Statement
  • SandboxSpec cannot accept a create-time policy. The template-based API can, but requires a named workload template.
  • WorkspaceRef omits identity, resource version, and deletion metadata. SandboxRef omits the stored specification, deletion metadata, and detailed status such as startup conditions. Their conversions also replace some absent fields with defaults.
Impact / Why This Matters

Callers must construct raw gRPC requests and handle raw responses for operations the SDK otherwise supports. This adds integration code to maintain as OpenShell evolves.

Deployment automation needs these details to identify the resource it created, detect configuration drift, and distinguish readiness, deletion, and incomplete observations.

Proposed Design

Before — current API: Image-based creation with policy requires a raw request. Reading the stored specification and detailed status also requires a raw call.

use openshell_sdk::raw::proto;

let mut grpc = client.raw_grpc();
let created = grpc.create_sandbox(proto::CreateSandboxRequest {
    workspace_scope: Some(proto::workspace_selector("default")),
    name: "worker".into(),
    spec: Some(proto::SandboxSpec {
        template: Some(proto::SandboxTemplate {
            image: image.clone(),
            ..Default::default()
        }),
        policy: Some(policy),
        ..Default::default()
    }),
    ..Default::default()
}).await?.into_inner().sandbox;

// Later: use raw GET to retain details omitted by SDK get_sandbox.
let observed = grpc.get_sandbox(proto::GetSandboxRequest {
    workspace_scope: Some(proto::workspace_selector("default")),
    name: "worker".into(),
}).await?.into_inner().sandbox;

After — illustrative API, not existing signatures: The same workflow uses SDK operations. Here, policy and resource() illustrate the requested capabilities; maintainers can choose their API shape.

use openshell_sdk::types::SandboxSpec;

let workspace = client.workspace("default");
let created = workspace.create_sandbox(SandboxSpec {
    name: Some("worker".into()),
    image: Some(image),
    policy: Some(policy), // Proposed create-time policy input.
    ..Default::default()
}).await?;
let created_metadata = &created.resource().metadata;

let observed = workspace.get_sandbox("worker").await?;
let stored_spec = &observed.resource().spec;
let lifecycle_status = &observed.resource().status;

Both excerpts assume an initialized client, an image string, and a policy. The before example was checked against the linked source revision, not compiled as a standalone program. The proposed resource access preserves optional fields and also applies to workspace create/get results. Callers keep their ownership checks and desired-state comparison.

Through public Rust SDK calls, a caller should be able to:

  1. Create or get a workspace and retain its identity and lifecycle metadata.
  2. Create a sandbox directly from an image with its intended policy supplied in the initial request.
  3. Inspect the returned resource, then read it later to compare stored configuration and status with desired state.

Expose the gateway's existing capabilities and returned resource information. Maintainers can choose the public API shape; access to the existing resource representation would suffice. Callers remain responsible for ownership checks and desired-state comparison.

Acceptance Criteria
  • Image-based creation accepts policy without requiring a workload template or subsequent policy update.
  • Workspace create/get exposes returned identity, resource version, labels, deletion metadata, and status.
  • Sandbox create/get exposes returned identity, metadata, stored specification, and status, including startup conditions.
  • These details are available from the create response itself, without a second GET to recover omitted fields.
  • Absent metadata, specification, or status remains distinguishable from a present default-valued object.
  • Tests and a usage example cover this workflow; existing default behavior is preserved and any source-compatibility implications are documented.
Alternatives Considered
  • Keep using raw gRPC: retains the downstream integration code.
  • Create a template solely to supply policy: adds another resource to manage.
  • Update policy after creation: cannot establish the intended policy in the initial request.
Agent Investigation

Source review confirmed both gaps in SDK types at main revision 0b351c4. No live gateway test was performed for this proposal.

Related: #2680 (workload/template API), #3398 (completed sandbox-scoped provider/policy/settings SDK methods), and #2565 (API/SDK stabilization). This request is limited to the create/read workflow above.

Checklist
  • I've reviewed existing issues and the architecture docs.
  • This is a design proposal, not a "please build this" request.
Vorherrschende Sprache
Rust
Sterne
15.4k
Forks
1.7k
Ø Merge
2 T. 6 Std.
Gemergte PRs (30 T.)
397

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 NVIDIA/OpenShell

Alle Issues in NVIDIA/OpenShell

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

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