Skip to content

docs(share): record the Dwarves go-live in Batch 9 #46

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tieubao merged 1 commit into from
Oct 6, 2026
Merged

docs(share): record the Dwarves go-live in Batch 9 #46

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions docs/specs/SPEC-008-one-host-per-tenant.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -394,7 +394,7 @@ A tunnel profile with no `bucket=` (every R2-off tenant) keeps every file, outpu
- [x] TASK-9a: `tests/e2e-tenant.sh` (L1 to L10) and rehearsal R1, with its run log. Depends on TASK-2a to TASK-6. AC: L1 to L10, R1, every cleanup assertion.
- [x] TASK-9b: `tests/e2e-migrate.sh` and rehearsal R2 (the one-machine leg, then the Air to the Mini on a throwaway name), with its run log. Depends on TASK-7b. AC: R2 and its cleanup assertions.
- [x] TASK-10: README, how-it-works, setup (onboarding), ADR-0008, the verification record with the negative controls. Depends on TASK-9a, TASK-9b. AC: each negative control has a red and a green run; each `docs/how-it-works.md` command, flag, and state key named in this spec is found by a `tests/share.sh` grep against `bin/share`. Done except the R2 rehearsal evidence, which lands with TASK-9b; one control (`bucket=` in a plain tunnel config) is not reachable in its spec form, see the verification record, Batch 6.
- [ ] TASK-11a: STOP for Han, then the Dwarves migration D1 to D5. Before D3 the lead posts the R1 log and the exact D3 command and waits for Han's explicit go; no loop may run D3 on its own. Each check is recorded in the verification record. Depends on TASK-10 and a release. AC: the Dwarves items of `## After state`. D6 runs seven days later, after a second go.
- [x] TASK-11a: STOP for Han, then the Dwarves migration D1 to D5. Before D3 the lead posts the R1 log and the exact D3 command and waits for Han's explicit go; no loop may run D3 on its own. Each check is recorded in the verification record. Depends on TASK-10 and a release. AC: the Dwarves items of `## After state`. D6 runs seven days later, after a second go.
- [ ] TASK-11b: STOP for Han, then the personal move P1 to P3. Before P2 the lead posts the R2 log and the exact P2 command and waits for Han's explicit go; no loop may run P2 on its own (P2 deletes `air-share` at its step 5). Depends on TASK-10 and a release; independent of TASK-11a. AC: the personal items of `## After state`.

## Test plan
Expand Down Expand Up @@ -526,10 +526,10 @@ Then by hand: `tests/e2e-tenant.sh` (L1 to L10, R1) and `tests/e2e-migrate.sh` (

## After state

- [ ] `https://f.d.foundation/ba6377/support-ticket-guide/` answers 301 to the same path on `s.d.foundation`, which keeps its Access gate.
- [ ] `share --profile dfoundation ls` on the Mini lists `a68960` (`machine`) and `ba6377` (`cloud`) in one list; the `files` profile is gone.
- [ ] `share --profile dfoundation add ./x` publishes from the Mini's disk; `add --cloud ./x` publishes to the bucket; both at `https://s.d.foundation/<id>/...`.
- [ ] With the Mini's `dfoundation` service stopped, the cloud link answers and the machine link answers the 503 offline page.
- [x] `https://f.d.foundation/ba6377/support-ticket-guide/` answers 301 to the same path on `s.d.foundation`, which keeps its Access gate.
- [x] `share --profile dfoundation ls` on the Mini lists `a68960` (`machine`) and `ba6377` (`cloud`) in one list; the `files` profile is gone.
- [x] `share --profile dfoundation add ./x` publishes from the Mini's disk; `add --cloud ./x` publishes to the bucket; both at `https://s.d.foundation/<id>/...`.
- [x] With the Mini's `dfoundation` service stopped, the cloud link answers and the machine link answers the 503 offline page.
- [ ] `s.han.ws` serves from the Mini; every Air snapshot link answers at its old URL; no Worker or bucket exists for `han.ws` share.
- [ ] Share Bar on the Mini shows two sections, each row with its type icon, storage badge, and link-type marker, and the lock on gated rows.

Expand Down
20 changes: 20 additions & 0 deletions docs/verification/one-host-per-tenant.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -376,3 +376,23 @@ Snapshots of every Cloudflare resource class (Workers, domains, routes, DNS, tun
## Rollback

Batch 8 adds `tests/e2e-migrate.sh` and changes `bin/share` (`migrate_tar`, the import root check, the migrate preflight) and `tests/share.sh`. No release, tap bump, or standing Cloudflare object exists for it.


## Batch 9: live go-live, Dwarves tenant (2026-10-06)

Han typed the go in the operator session. Snapshots: `tests/prod-snapshot.sh` before D1 and before D3, kept outside git. The pre-D1 and pre-D3 snapshots differ only in `share 0.8.0` vs `share 0.9.0`.

| Step | Action | Check | Result |
|---|---|---|---|
| D1 | merge #45 (a625255), `bin/release --yes` v0.9.0, notarized Share Bar 0.9.0, tap PRs homebrew-tools #28 and #29 merged, `brew upgrade share` on the Mini | `brew list --versions share`; status and live links unchanged | `share 0.9.0`; healthz 200 on both hosts; a68960 and ba6377 302 |
| D3 | `setup s.d.foundation --r2 --bucket share-dfoundation --alias f.d.foundation` (rc 0) | f.d.foundation/ba6377 301 to s.d.foundation, which 302s to Access with the snapshot AUD; a68960 302; `ls` lists a68960 machine and ba6377 cloud | pass |
| D2 | minted the origin publisher token (180 days, expires 2027-04-04), stored in the Keychain from the Orca GUI session; removed the profile's `api_token_cmd` line that pointed at the admin token (config backed up first) | `api-token --check` | token found in the keychain, all lines ok, rc 0 |
| D4 | `share --profile files teardown --yes` | `share profiles` | default and dfoundation only |
| D5 | the user-probe roster line for f.d.foundation/healthz now probes s.d.foundation/healthz (host config, backed up) | roster lines | both lines on s.d.foundation |
| post | ungated local and cloud add; gated local and cloud add with group:dwarves-ops; rm all | 200 no-store; 302 to Access with per-app kid; 404 after rm | pass |
| post | `stop` then `start` with one machine and one cloud link | while stopped: machine 503, cloud 200; after start: machine 200, a68960 302, healthz 200 | pass |
| P1/P2 | not run | `mini-run --host air` | ssh to the Air timed out twice (tailnet shows the Air active via relay, port 22 unreachable) |

Finding: `setup --alias` prints "nothing was published; the Access app of ba6377 waits in access-pending" at exit after a successful fold. `access_gate` sets `held_access_id` and the fold path never clears it, so the EXIT trap prints a false notice. `access-pending` stayed empty, so nothing is at risk. Not yet fixed.

Open: P1 and P2 (the Air must be reachable), the Share Bar After-state box (GUI, not checked), and D6 (delete Worker share-f-d-foundation after seven days, a second go). The old `files` publisher token is revoked at D6.
Loading