Repository navigation
chore(cloud): add the relay fence broker, ops console, Terraform root, scripts, and 24 cloud-* workflows - #18413
Merged
Merged
Conversation
Import the relay server and its wire contract under cloud/ as an independent pnpm workspace, with a Cloud Verify workflow that builds, tests, and secret-scans it.
The sanitized import dropped the checks that read dev/scripts and infra/terraform because neither shipped. Both land in this branch.
…, and scripts Copies the private repository's relay side: the IAM-only fence broker, the operations console and incident monitor, the relay Terraform root with its backend configuration and tfvars, and the deploy/capacity/admission/rehome/ monitoring scripts the workflows call, with their contract tests, contracts, and fixtures. The foundation and apps Terraform roots and the API and auth services stay private. Four surfaces that spanned both trees are narrowed to the relay side rather than left with a dangling read: the infra runner and the root-partition and workload-identity-condition renderers now declare only the relay root, and the Cloud SQL rollout census drops the six app workflows that are not here.
…ase action Each workflow is copied under a cloud- prefix, runs from cloud/ through a workflow-level defaults block, and resolves pnpm and the Node cache against cloud/package.json and cloud/pnpm-lock.yaml. Display names are unchanged because the recovery chain matches on them; every reusable call, gh dispatch, and jq run-path check was repointed to the prefixed filenames. Every job that can start on its own is gated on the repository variable ORCA_CLOUD_OPERATIONS_ENABLED, so both scheduled triggers and every manual dispatch skip without running a step until the owner enables them. Reusable jobs inherit the caller's gate rather than restating it. A new contract test pins the gate, the three chained display names, and the absence of any repository secret other than the automatic token.
Format-checks, initialises without a backend, and validates cloud/infra/terraform on the same pinned Terraform the private repository's CI uses. Fork pull requests reach this workflow, so the job configures no backend and holds no credential.
…lay surface A job-level `if:` is evaluated before the job's environment is resolved, so every `vars.PRODUCTION_*` / `vars.STAGING_*` check in one reads empty in this repository and would skip the job with no failing run to notice. The five job-level checks are removed; each variable is still read where it is used, in the authentication step that resolves it. The multi-target gate loses its whole mode branch: with both identity clauses gone the two arms are exhaustive, so only the branch check remains. CODEOWNERS claims the workspace, the cloud-* workflows, and the lease action.
Contributor
|
|
Too many files changed for review (379 files, 100 file limit). Bypass the limit by tagging |
…epo linters The action lives outside cloud/, so the root oxlint (curly) and oxfmt apply to it; the copied files were on orca-cloud's prettier style.
…ease tests from cloud/ defaults.run.working-directory: cloud does not exist before actions/checkout, so the eight guard/gate steps that run first (and the two checkout-free jobs, clock-skew and requeue) failed to start. Pin those steps to '.'. The pretest lease-action paths are ../.github from cloud/, and the two bare pnpm setups read cloud/package.json instead of the root's pnpm 12. Cloud Verify now also triggers on the lease action.
…of the public tree Drop the two runbooks that walk through the foundation/apps roots, trim the Cloud SQL consumer contract's source notes to what the relay needs, scan the lease action's history in Cloud Verify, and exclude that action from the monorepo formatter so syncs from the private repo stay byte-identical.
…ccept identity change Ports orca-cloud f24f3b4 (#464). The Terraform root is byte-identical to that commit, including the new github_accepted_repositories variable and relay-github-workflow-trust.tf, so every relay provider now admits stablyai/orca alongside stablyai/orca-cloud. The tfvars already name this repository's cloud- prefixed workflow paths on the stablyai/orca arm. Ten scripts were three-way merged so the public-repo adaptations survive: the relayWorkflowFile/relayWorkflowPath/readRelayWorkflow indirection, the census keys, and the workflow directory depth. The condition renderer keeps the apps root declared and skips it when the directory is absent, so its expectations stay a straight copy of the private original. The staging deploy identity's rendered-length pin keeps the private repository's 797 and derives this copy's difference from the filename prefix.
This was referenced Sep 3, 2026
Jinwoo-H
added a commit
that referenced
this pull request
Sep 21, 2026
…ogging
A read-only production plan for production-gce-c7 showed the live US cell
backends carry no `log_config` at all, while relay-gce-cells.tf has declared
`log_config { enable = true, sample_rate = var.relay_gce_cell_log_sample_rate }`
on every cell backend since the Terraform root landed in 3eec77c (#18413).
Nothing has applied it because every production apply since is a per-cell
targeted plan that names only the template and the MIG.
So the real canary plan's backend moves two paths, not one:
`["connection_draining_timeout_sec", "log_config.0"]`. The drain-only validator
rejected exactly that plan, which would have stranded the cell mid-wave after
the drain had already started.
Accept both, each optional, for this cell's backend only: the drain landing on
RELAY_CELL_CONNECTION_DRAIN_SECONDS, and a log_config of exactly one block with
`enable = true` and `sample_rate` equal to RELAY_CELL_LOG_SAMPLE_RATE, the
declared default of a variable no environment file overrides. Any third path,
a different sample rate, disabled logging, another cell, or a replacement still
fails. The accepted paths are reported as `backendUpdate`, which the resume
branch now reads instead of the drain-only flag.
Verified against the real production plan: the masked, three-target plan for
production-gce-c7 contains exactly that cell's template, MIG, and backend
service and nothing else, and this validator returns
`{"changes":2,"backendUpdate":["connection_draining_timeout_sec","log_config.0"]}`.
Claude-Session: relay-same-cap-targets-cell-backend
9 tasks done
Jinwoo-H
added a commit
that referenced
this pull request
Sep 21, 2026
…gs inside each same-cap wave (#21860) * chore(relay): target each cell's backend service from the same-cap job The 60 s connection drain timeout merged in #21848 has no safe apply path. A root plan scoped to the backend services alone still pulls every `google_compute_instance_template.relay_gce_cell` in as a dependency, and standing image drift turns all 29 into replacements, so applying it would roll the fleet at once. Add `google_compute_backend_service.relay_gce_cell["${TARGET_CELL_ID}"]` to both plan invocations in the per-cell same-cap job, next to the template and MIG it already targets, and teach the reviewed plan validator to allow exactly one extra change: an in-place update of that one cell's backend whose only changed attribute is `connection_draining_timeout_sec`, landing on the constant `validate-relay-asia-topology-plan.mjs` exports. Any other attribute, any other resource, or a backend for another cell still fails the validator. The accepted update is reported as `connectionDrainUpdate` and kept out of `changes`, so the apply step's stranded branch and the resume step's drift branch keep reading the template-and-MIG count they were written against; the resume branch additionally accepts a plan whose only pending change is that drain update, which restarts nothing. Claude-Session: relay-same-cap-targets-cell-backend * fix(relay): also let the same-cap wave apply this cell's LB request logging A read-only production plan for production-gce-c7 showed the live US cell backends carry no `log_config` at all, while relay-gce-cells.tf has declared `log_config { enable = true, sample_rate = var.relay_gce_cell_log_sample_rate }` on every cell backend since the Terraform root landed in 3eec77c (#18413). Nothing has applied it because every production apply since is a per-cell targeted plan that names only the template and the MIG. So the real canary plan's backend moves two paths, not one: `["connection_draining_timeout_sec", "log_config.0"]`. The drain-only validator rejected exactly that plan, which would have stranded the cell mid-wave after the drain had already started. Accept both, each optional, for this cell's backend only: the drain landing on RELAY_CELL_CONNECTION_DRAIN_SECONDS, and a log_config of exactly one block with `enable = true` and `sample_rate` equal to RELAY_CELL_LOG_SAMPLE_RATE, the declared default of a variable no environment file overrides. Any third path, a different sample rate, disabled logging, another cell, or a replacement still fails. The accepted paths are reported as `backendUpdate`, which the resume branch now reads instead of the drain-only flag. Verified against the real production plan: the masked, three-target plan for production-gce-c7 contains exactly that cell's template, MIG, and backend service and nothing else, and this validator returns `{"changes":2,"backendUpdate":["connection_draining_timeout_sec","log_config.0"]}`. Claude-Session: relay-same-cap-targets-cell-backend
enrick-dev
pushed a commit
to enrick-dev/orca
that referenced
this pull request
Oct 15, 2026
…, scripts, and 24 cloud-* workflows (stablyai#18413) Phase 6 of the relay split: the relay's deploy/operate surface moves under cloud/ with 24 cloud-* workflows gated on ORCA_CLOUD_OPERATIONS_ENABLED, the Cloud SQL rollout lease action, the relay Terraform root (dual-accept identities for both repositories), scripts, docs, CODEOWNERS, and a terraform validate job in Cloud Verify.
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.
Phase 6 of the relay split: the relay's full deploy/operate surface moves into this repo under
cloud/, so nothing relay-related needsstablyai/orca-cloudany more.What lands
cloud/apps/relay-fence-broker,cloud/apps/relay-ops(plus a sync ofcloud/apps/relayandcloud/packages/relay-contractto orca-cloud main).cloud/infra/terraform: the relay Terraform root, byte-identical to orca-cloud main. The foundation and apps roots (Cloud SQL, API, auth) stay private.cloud/dev/scripts+cloud/dev/contracts: the relay script closure and its tests;relay-repository.mjsis the one place naming the repository, thecloud-filename prefix, and the workflow directory depth..github/actions/cloud-sql-rollout-leaseand 24 workflows as.github/workflows/cloud-*.yml. Display names are unchanged so theworkflow_runchain (Prove → Recover → Requeue) still matches; every top job is gated on the repo variableORCA_CLOUD_OPERATIONS_ENABLED == 'true'(currentlyfalse), so nothing runs, including the two schedules, until the cutover flips it.Cloud Verifygains aterraform fmt -check+validate -backend=falsejob. It still has no environment and noid-token, so fork PRs stay inert.cloud/,cloud-*.yml, and the lease action.Guarantees
cloud-*.ymlreferencessecrets.*other thanGITHUB_TOKEN(test).if:reads an environment-scoped variable (they read empty before the environment binds and skip the job silently; see orca-cloud Use fish species for default worktree names #462).cloud/and.github/clean; nonode_modules,dist,.tfstate, or.tfplanin the tree.cd cloud && pnpm install --frozen-lockfile && pnpm test: relay 428 passed, fence broker 16, ops 75, scripts 130 + 493.GitHub-side setup already done:
productionandstagingenvironments (deployment branch policymain) with the 14 + 9 relay variables mirrored from orca-cloud;ORCA_CLOUD_OPERATIONS_ENABLED=false; evaluate-mode rulesetmain-cloud-paths-review.Cutover order after merge: orca-cloud dual-accept apply (both envs) → set
ORCA_CLOUD_OPERATIONS_ENABLED=true→ verifycloud-monitor-relay-clock-skew→cloud-monitor-relay-production→cloud-power-relay-staging→ staging deploy path → production publish → retire the orca-cloud copies and drop the orca-cloud arm.