bug: driver-controlled runtimes do not apply live policy revisions
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
まず、ValidateSandboxCreate と CreateSandbox を通じて MxcComputeBackend を追跡し、次に既存の GetSandboxConfig と ReportPolicyStatus のコントラクトを調べます。再現手順と openshell policy status/--wait の動作を使って、リビジョンがどのように配信され、確認応答されるかを検証します。列挙されたライブ適用、失敗、拒否、確認応答、再接続、再起動、ドキュメントのケースがテストでカバーされれば完了です。
索引モデルが issue の本文から書いたものです。
説明
User Story
As an OpenShell operator, I want policy updates accepted for a running sandbox to be applied live by its active compute runtime, so that the policy reported by the gateway always matches the policy the workload is actually enforcing.
Problem Statement
PR #2823 gives driver-controlled runtimes the canonical create-time policy in DriverSandboxSpec.policy and removes the MXC-specific rejection for live policy mutations. The MXC backend reads and maps that policy only during ValidateSandboxCreate and CreateSandbox; it does not fetch later revisions or report their load status.
The gateway can therefore accept and persist a later policy revision for a running driver-controlled sandbox without the runtime consuming it. The desired policy returned by the gateway then differs from the policy enforced by the workload.
The existing sandbox configuration contract already exposes later revisions through GetSandboxConfig and load acknowledgement through ReportPolicyStatus. This bug does not require a compute-driver reconcile RPC.
Impact / Why This Matters
A tightening update can appear accepted while the workload continues under the previous policy. A loosening update remains unavailable even though the gateway records it. --wait can time out because the driver never reports the revision as loaded.
The current workaround is to delete and recreate the sandbox so the policy is delivered again at creation. That interrupts the workload, discards runtime state, and violates the expected live policy-update workflow.
Acceptance Criteria
- A driver-controlled runtime without the standard supervisor observes every new effective policy revision for each running sandbox.
- The runtime applies supported live policy changes without deleting or recreating the sandbox.
- The runtime calls
ReportPolicyStatuswith the exact revision and reportsloadedonly after enforcement has switched to that revision. - A load or enforcement failure is reported as failed and is visible through
openshell policy statusand--wait. - A policy change the selected runtime cannot enforce live is rejected before it can be mistaken for an applied revision.
- Reconnects, gateway restarts, and temporarily missed notifications converge the runtime to the latest effective revision.
- Tests cover successful live application, rejected unsupported changes, failed application, acknowledgement, and catch-up after reconnect/restart.
- MXC documentation no longer claims live revision support unless the MXC runtime implements and validates this behavior.
Reproduction Steps
- Build the Windows gateway from PR #2823 with the MXC driver enabled.
- Create and start an MXC sandbox with a policy that the driver maps successfully.
- Submit an otherwise valid live policy replacement or merge update with
openshell policy set --waitoropenshell policy update --wait. - Observe that the gateway persists the new revision, while
MxcComputeBackendcontinues using only the policy captured duringCreateSandboxand never acknowledges the later revision. - Observe that
--waitcannot confirm the revision as loaded and the running workload remains governed by its create-time policy.
Environment
- OpenShell: PR #2823 at
d26297a214b40809e4b4dfcd5513e3e257b0552c - OS: Windows 11 Insider build supported by MXC
- Runtime, deployment, or integration: in-process
openshell-driver-mxc, without the standard sandbox supervisor - Verification note: identified through code review; native Windows execution was not available on the review host
Related Work
- #2417
- #2823
- 主要言語
- Rust
- スター
- 8.7k
- フォーク
- 1.3k
- 平均マージ
- 2日 6時間
- マージ済み PR(30日)
- 297
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA/OpenShell のほかの issue
-
area:docs
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
state:triage-needed
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
area:cli state:validated
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
state:triage-needed
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
area:build spike state:review-ready state:stale
難易度 2/5 半日 初心者へのやさしさ 68/100
NVIDIA/OpenShell の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
state:needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
zed-industries/zed#64680 · コメント 2 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
RustPython/RustPython#8802 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
TheLarkInn/aipm#2390 ·