Skip to content

#1 docs: GCP provisioning runbook (bucket, writer SA, grants, key) - #14

Merged
gregoryfoster merged 5 commits into
mainfrom
1-gcp-provisioning
Oct 2, 2026
Merged

gregoryfoster merged 5 commits into
mainfrom
1-gcp-provisioning

Conversation

@gregoryfoster

Copy link
Copy Markdown
Contributor

The spec §6 "gcloud block", as a section of docs/DEPLOYMENT.md. It is drafted for the operator to run where gcloud is authenticated to co-gcs; nothing in this repo runs it. Refs #1 (plan step 8).

  • Bucket gs://co-gcs-processor: US-WEST1, STANDARD, uniform bucket-level access, public access prevented, no lifecycle. GCS's default soft delete is kept, as on co-gcs-replicator. This mirrors Replicator's docs/INFRASTRUCTURE.md.
  • Writer co-gcs-processor-writer: objectCreator + objectViewer on co-gcs-processor, and objectViewer on co-gcs-blobs. No delete anywhere (spec D4).
  • Watcher's reader: proposed as co-gcs-blob-reader, the identity Watcher already reads gs:// blobs with (its GCS_BLOB_CREDENTIALS). The text is derived from blobs it can already read, so it gains nothing new. This step waits on watcher#325.
  • The key goes onto co-processor over SSH stdin, from a 700 temp dir removed on exit. Then the env line and a read-only preflight of both buckets as the writer.

Checked: every bash block passes bash -n, and the Python preflight compiles. The suite (215) and ruff are clean.

Review points:

  1. Should Watcher's reader be co-gcs-blob-reader or a new identity?
  2. Keep the default 7-day soft delete?
  3. Is ssh co-processor.exe.xyz how you reach the VM?

🤖 Generated with Claude Code

gregoryfoster and others added 5 commits October 2, 2026 17:47
The spec §6 "gcloud block", drafted for the operator; nothing here runs it.
It mirrors the cohort's buckets (Replicator's INFRASTRUCTURE.md): co-gcs,
US-WEST1, STANDARD, UBLA, public access prevented, no lifecycle, and the
default soft delete kept, as on co-gcs-replicator.
- co-gcs-processor-writer: objectCreator + objectViewer on
  co-gcs-processor, objectViewer on co-gcs-blobs; no delete anywhere.
- Watcher's reader is proposed as co-gcs-blob-reader, the identity Watcher
  already reads gs:// blobs with (its GCS_BLOB_CREDENTIALS); it gains
  nothing new. Gated on watcher#325's answer.
- The key goes onto co-processor over SSH stdin from a 700 temp dir that
  is removed on exit; then a preflight of both buckets as the writer.
Prerequisites table: links the section; the broker credential row records
the 2026-10-01 mint and digest post.

Refs #1

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…10-01)

broker#75 step 2 landed (processor live, observo deleted); PING broker as
processor returned PONG at 22:09:36Z; processor ensure-group created
content.process and processor.process at 22:09:41Z, verified as processor
with XINFO STREAM FULL (empty, group at 0-0, lag 0).

Refs #1

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…on is the record, not a draft

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…t and is tracked in #15

Direct under traffic (NAT hairpin), DERP after idle; no longer an open broker#75
finding.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ader, per the bucket's IAM policy)

watcher#325 has not yet confirmed that identity; the runbook says what to do if
Watcher names another.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant