Repository navigation
Conversation
scripts/factory-edge-run.sh stages the three workloads, runs the demo against them and removes them again, even if the demo fails, and exits with the demo's status. It is for someone who just wants to see it work; a presenter still stages ahead and runs the two scripts separately. A run takes about 20 seconds on the demo Mac, down from 32 for the same steps. Two things made it slower than it needed to be. The staging script started the three workloads one after another, each waiting out its own launch, so they are now started together and each start is checked afterwards. And the built-in waits (a 10 second delay before the maintenance request and a 5 second lookup cadence) are shortened to 3 and 2 seconds in the one-command run, which is about a minute long and so does not grow the audit record meaningfully; a presenter staging ahead keeps the longer defaults. scripts/factory-edge-demo.md is a one-page guide in plain language: what it shows, the one command, what the output means, what to do when it does not pass, a one-time setup for a new Mac, and what the demo does not show. The hermetic test now also covers the runner: a clean run, a failing run that still removes the staged workloads, and a staging failure.
Collaborator
Author
|
Closing: the demo is simpler than this. The factory-edge demo should be the raw version in the proposal (three workloads, one refused request, the others carry on, the evidence), without staging, assertions or teardown. That is now a single short script in a separate PR. This PR was part of the verification harness, so it is superseded, not lost; reopen it if the harness is wanted. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #5495. Makes the factory-edge demo something a person can simply run, and writes down how in one page.
One command.
scripts/factory-edge-run.shstages the three workloads, runs the demo against them and removes them again, even if the demo fails (and on an interrupt), and exits with the demo's status. It is for someone who just wants to see it work. A presenter still stages ahead and runs the two scripts separately, which the guide describes.Faster. A one-command run takes about 20 seconds on the demo Mac, down from 32 for the same steps (staging 7 s, the run 12 s). Two things were slower than they needed to be: the staging script started the three workloads one after another, each waiting out its own launch, so they now start together and each start is checked afterwards; and the built-in waits (a 10 s delay before the maintenance request, a 5 s lookup cadence) are 3 s and 2 s in the one-command run. A presenter staging ahead keeps the longer defaults, because every lookup is a signed audit entry and the record grows for as long as the workloads run.
A short guide.
scripts/factory-edge-demo.mdis one page in plain language: what the demo shows, the one command, what the output means, what to do when it does not pass, a one-time setup for a new Mac, and what the demo does not show.What is not changed. A launch still takes a few seconds on this release, so the replacement is a live launch and the staged launches take most of the remaining time; that is the verification cost written up in #5487 and designed in #5515. This does not fix it.
Verification. The hermetic test now also covers the runner (a clean run, a failing run that still removes the staged workloads, and a staging failure) and passes. A live run on the demo Mac against the v0.28.0-rc.2 release passed all 11 checks in 19 seconds and left no machines or processes behind. Spec hygiene, overclaim, doc links and honesty gates pass. Independent of #5504 (the
--checkpreflight): staging runs its own prerequisite checks, and DNS is added to them when #5504 lands.