bug: driver-controlled runtimes do not apply live policy revisions
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu bằng cách lần theo MxcComputeBackend qua ValidateSandboxCreate và CreateSandbox, sau đó kiểm tra contract hiện có của GetSandboxConfig và ReportPolicyStatus. Sử dụng các bước tái hiện và hành vi của openshell policy status/--wait để xác minh cách các revision được phân phối và xác nhận. Công việc được xem là hoàn tất khi các trường hợp được liệt kê về áp dụng trực tiếp, lỗi, từ chối, xác nhận, kết nối lại, khởi động lại và tài liệu được bao phủ bằng các test.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Rust
- Star
- 8.7k
- Fork
- 1.3k
- Merge trung bình
- 2 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 297
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của NVIDIA/OpenShell
-
area:docs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
state:triage-needed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
area:cli state:validated
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
state:triage-needed
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
-
area:build spike state:review-ready state:stale
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 68/100
Tất cả issue của NVIDIA/OpenShell
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
state:needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
zed-industries/zed#64680 · 2 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
RustPython/RustPython#8802 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
TheLarkInn/aipm#2390 ·