You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Stabilize public API, SDK, and extension contracts for 0.1.0 #2565
Before the OpenShell 0.1.0 release, review and stabilize every public API, SDK, and extension contract. This is the final planned opportunity to make coordinated breaking changes before those surfaces are treated as stable as defined in RFC-0014.
We'll use this ticket to track specific API changes as child tickets.
Scope
Contract inventory and review
Create an inventory of all externally consumed contracts and identify an owner for each surface, including:
Gateway gRPC services, messages, methods, status/error behavior, and transport metadata
SDK APIs and generated client types across supported languages
CLI- or configuration-facing representations derived from public API types
Extension contracts, including gateway interceptors, supervisor middleware, compute drivers, credential drivers, and other supported extension points
Serialization formats, enum behavior, identifiers, pagination, optionality/defaults, version negotiation, and capability discovery
For every contract, review naming, structure, semantics, consistency, extensibility, error handling, and compatibility risks. Explicitly classify each surface as public/stable, public/experimental, or internal.
Final pre-beta breaking-change pass
Resolve the contract changes identified by the review as one coordinated pre-beta stabilization effort.
Remove or replace APIs that we do not intend to support during beta.
Align equivalent concepts and behaviors across gRPC, SDKs, CLI/configuration, and extension surfaces.
Regenerate affected clients and fixtures and update all in-repository consumers.
Publish migration notes that enumerate every breaking change and show consumers how to update.
Establish a cutoff after which public beta contracts follow the compatibility policy below.
Before issuing mutations, an external client needs to determine whether its SDK/protobuf contract and the active Gateway and compute driver are compatible.
GetGatewayInfo exposes the Gateway version and driver identity, but method presence alone does not communicate whether a behavior is stable, experimental, or driver-dependent.
Is the intended beta compatibility mechanism:
Gateway/SDK versions plus a published compatibility matrix;
protobuf descriptor compatibility;
machine-readable capability and stability discovery; or
some combination of these?
Would a small external-consumer fixture exercising version and capability negotiation be useful as one of the release gates described here?
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
Filed a child issue resolving one of the blocking questions from the inventory (which SDK is the reference shape for provider/policy/settings coverage) and proposing a fix for part of finding #5 (raw being the only path to most of the API): #3398.
Also resolved the other two blocking questions from the inventory while looking into this:
@openshell/sdk location/ownership: it's sdk/typescript, published as @nvidia/openshell-sdk, not a napi-rs wrapper — the docs describing the old napi plan (RFC 0007/0008, both closed unmerged) are stale and should be corrected.
Sandbox metadata server classification: no longer applicable — that standalone module doesn't exist anymore; GCE metadata emulation is now implemented via proxy interception in the supervisor, the same mechanism as other provider credential injection.
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
Activity
dredozubov commentedon Aug 6, 2026
Before issuing mutations, an external client needs to determine whether its SDK/protobuf contract and the active Gateway and compute driver are compatible.
GetGatewayInfoexposes the Gateway version and driver identity, but method presence alone does not communicate whether a behavior is stable, experimental, or driver-dependent.Is the intended beta compatibility mechanism:
Would a small external-consumer fixture exercising version and capability negotiation be useful as one of the release gates described here?
25 remaining items
github-actions commentedon Sep 9, 2026
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
politerealism commentedon Sep 16, 2026
Filed a child issue resolving one of the blocking questions from the inventory (which SDK is the reference shape for provider/policy/settings coverage) and proposing a fix for part of finding #5 (
rawbeing the only path to most of the API): #3398.Also resolved the other two blocking questions from the inventory while looking into this:
@openshell/sdklocation/ownership: it'ssdk/typescript, published as@nvidia/openshell-sdk, not a napi-rs wrapper — the docs describing the old napi plan (RFC 0007/0008, both closed unmerged) are stale and should be corrected.github-actions commentedon Oct 8, 2026
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.