Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

nvx-rs: put the process, NVXS, and sandbox store APIs behind consumer-selected features

Aperta
  • Qualcosa non va?
#648 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend, build-system

Direzione di ricerca

Start with nvx-rs/Cargo.toml to map the existing features and their dependencies, then trace the listed nvx::host::process, nvx::host::nvxs, and nvx::host::store modules and their consumers, including the cli feature. Review tests/runtime-adapter, .github/actions/check-nvx-rs/action.yml, aci_edge_sandboxes, and nvx-rs/README.md for required configurations. Done means documented feature combinations build without warnings on Linux and Windows at the minimum Rust version, CI covers consumers with each feature and without them, and rustdoc documents the gates.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Related to #620 and #535.

Summary

The host feature of nvx-rs, which is on by default, enables every host API. #625, #627, and #628 add three APIs that only some consumers need:

Module Pull request Purpose
nvx::host::process (verified process references, event-driven exit waits) #625 Refer to a process across restarts of the orchestrator without signaling a reused process ID
nvx::host::nvxs (application-neutral NVXS session) #627 Open a session with a guest agent
nvx::host::store (sandbox store, launch journal, runtime identity) #628 Let a successor orchestrator take over or stop the VMs of its predecessor, as a live update of the host orchestrator requires

Put each behind a Cargo feature that a consumer enables only when it needs that capability, so that consumers that do not use it compile less code, pull fewer dependencies, and expose a smaller API. For example, the store could sit behind a host-orchestrator-live-update feature, since it serves the live update of the host side.

Proposal

  • Define one feature per capability. The names are open; the feature names should describe what the consumer gets, as host-orchestrator-live-update does, rather than the module.
  • Express the dependencies between them in Cargo.toml. For example, the store holds VMMs through verified process references, so its feature enables the process feature.
  • Decide whether host, and therefore default, enables the new features. Leaving them out makes them opt-in. Enabling them keeps every current consumer building unchanged but saves nothing by default.
  • Gate the other crate code that uses these modules, such as the cli feature, behind the same features or have those features enable them.
  • Consider whether existing host modules would benefit from the same treatment, but keep that for separate issues.

Requirements

  • Every documented feature combination builds without warnings, on Linux and Windows, at the minimum supported Rust version.
  • tests/runtime-adapter, which checks the configurations that consumers build, covers a consumer with each new feature and one without any.
  • check-nvx-rs builds and tests the new configurations; aci_edge_sandboxes keeps building, with the features it needs enabled explicitly.
  • nvx-rs/README.md and the crate documentation list each feature, and rustdoc marks the gated items with the feature they need.

Acceptance criteria

  • Building nvx-rs with only host compiles none of the gated modules if the decision is to make them opt-in.
  • Enabling a feature makes its module and its dependencies available, and nothing else.
  • CI covers each new configuration.
Lingua principale
Python
Stelle
408
Fork
28
Merge medio
16h 35m
PR unite (30g)
348

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/nvx

Tutte le issue di microsoft/nvx

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.