Repository navigation
Share Machine installation and add bounded CLI upgrades - #827
Conversation
…rades-825 # Conflicts: # crates/ployzd/src/installer/mod.rs # crates/ployzd/src/installer/release.rs
nick-potts
changed the title
# Conflicts: # crates/ployzd/src/machine/local_machine/container.rs # crates/ployzd/src/volume_plugin.rs
# Conflicts: # crates/ployzd/src/daemon.rs
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 70b9fa1fb0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad510052f1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let mut command = Command::new("systemd-run"); | ||
| command | ||
| .arg(format!("--unit={unit}")) | ||
| .args(["--collect", "--quiet"]) |
There was a problem hiding this comment.
When ployz-uninstall runs while this transient upgrade unit is active, it can report success before the worker finishes: systemd-run --help documents --wait as the option that waits for the service to stop, but this invocation omits it, while scripts/uninstall.sh:35-66 stops only the daemon and volume plugin before deleting the units, binary, state, and service account. The upgrade worker can subsequently recreate those files or the data directory and attempt to restart the service, leaving a partially reinstalled or unstartable Machine; the uninstaller should detect and stop or wait for active upgrade ownership before deleting anything.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in follow-up PR #845 (d8decf6). Uninstall synchronously stops upgrade workers, holds the shared installation flock throughout deletion, stops the daemon and any worker admitted during the initial shutdown, and aborts before cleanup if inspection, shutdown, or lock acquisition fails. The existing Rung 1 lifecycle shell contract reproduces the original race and covers seven success/failure scenarios.
* Start shared Machine installer and upgrade implementation (#822) * feat(ployzd): install Machines through daemon * fix(ployzd): harden Machine installer * test(ployzd): execute installer contracts * feat(setup): use shared Machine installer * fix(ployzd): tighten installer host boundaries * feat: add bounded machine upgrades * fix(setup): address adapter review findings * fix: preserve upgrade attempt evidence * fix(setup): verify downloads before staging * fix(setup): verify downloads before staging * test(compose): create ignored FIFOs portably * test(compose): create ignored FIFOs portably * test(compose): use POSIX mkfifo fixture * test: qualify bounded machine upgrades * test(compose): use POSIX mkfifo fixture * fix(setup): refresh SSH groups after install * fix(setup): refresh SSH groups after install * Fix provisioned volume metadata registration * fix(upgrade): own mutation admission and durable outcomes * Fix provisioned volume metadata registration * test(machine): await guarded local mutations * fix(installer): reject nonstandard system paths * fix(upgrade): reject nonstandard activation paths * test(upgrade): isolate qualification from public DNS * Let Docker own provisioned volume creation * Let Docker own provisioned volume creation * fix(upgrade): close implementation review findings * refactor(build): group execution admission * fix(installer): own launches and retain live smoke backing --------- Co-authored-by: Codex <codex@codex-vm.tailcb9c5.ts.net>
Machine setup and explicit CLI upgrades now use one Rust installer. Setup prepares the host; software-only upgrades preserve Machine identity, Cloud Pairing, configuration, Docker, and application data. A bounded systemd worker survives client disconnection and daemon replacement, records the exact target and observed outcome, and excludes conflicting Machine mutations.
The CLI upgrades selected Machines in order and stops on failure or uncertainty, reporting remaining Machines as unattempted. Provisioned-volume preparation reserves capacity while Docker owns volume creation and metadata registration.
Review follow-ups transfer acceptance and launch into a task that owns installation exclusion. ZFS smoke backing loses automatic deletion ownership before Pool creation; only verified cleanup may remove it. Regression tests reproduce caller cancellation during launch and uncertain Pool cleanup.
Validation:
70b9fa1and a version-only beta.36 target1750b739. It verified normal ZFS setup, non-empty Cloud Pairing preservation, client disconnection, corrupt-preflight rejection, failed-activation diagnostics, explicit repair, and 126 successful application probes with zero failures.Cloud upgrade UI is deferred to #826.
Part of #822.
Closes #823
Closes #824
Closes #825