Repository navigation
Deploy creates the materialization store's staging sibling (#13690 regression) - #13732
Merged
Merged
Conversation
Every compute build on srv1 refused 'store unavailable: could not create the compute directories' since dd786ba moved compute to the durable store under /var/lib/gunbc: the deploy declared materialization-store but not the '-staging' sibling compute stages into, and the service user cannot create it under the root-owned /var/lib/gunbc. The sibling's path now derives once in std.materialization_store_grant, consumed by compute_staging_dir and by a new srv1 host-directory member. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… staging sibling Generated by generated_artifact_gate main_wet_one on this tree (keeps #13723's fabric-storage-control grant). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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.
Summary
On srv1, every compute build has refused with
store unavailable: could not create the compute directoriessince #13690 (dd786baf) moved compute onto the durable store at/var/lib/gunbc/materialization-store. Compute stages into a sibling directory,<store root>-staging. The deploy declaredmaterialization-storeas a srv1 host directory, but not that sibling. The service user cannot create it under the root-owned/var/lib/gunbc, so the directory never existed.Production picks this up on its next deploy from main. Reported to and confirmed by smart-gull-336, whose #13690 introduced it; they asked that this land first.
Fix:
std.materialization_store_grant materialization_store_staging_root_path.compute_staging_dirand a newmaterialization-store-stagingmember ofgunbc.live_deploy.spec deployment_srv1_host_directoriesboth consume it, so the producer and the deploy cannot disagree.generated_artifact_gate main_wet_one. It adds the staging directory'sstatreadback grant and keeps Deployment risk D2 (3/4): role-singleton assess-and-admit with A2 in-place apply #13723'sfabric-storage-controlgrant.Known gap: the store's declared read/write grant envelope covers the store root but not the sibling. The annotation on the new function says so; modeling the sibling inside the envelope is not attempted here.
Evidence
Root cause, observed directly on the srv1 lab:
compute_request_cli operation=buildreturned the outcome above verbatim. Compute last succeeded at 04:44; the store's identity file was created at 04:56. Lineages based beforedd786bafcompiled, and those based after it did not.Executed on srv1 at
02b3536(this branch merged with mainc6a38b4), seed built from that tree:devboot_subject_identity_witness22/22, including the new claims: the staging sibling is a host-directory demand, and it reaches the deploy apply path.compute/work_request_witness_test23/23ci/deploy_sudoers_host_union_witness_test2/2live_deploy/emit83/84 anddeploy_mutation_gate_witness12/13. The two non-holding claims also fail on mainc6a38b4; they are Deploy blockers: tailnet door binds in a service-owned directory; grant-list probe reads its whole listing #13705's sudoers-install regression, which Fixes found bringing up the srv1 lab: sudoers install regression, ALL grant, subshell truncation, host-keyed Claude offer, placement-record type #13720 fixes.Live: deploying this change to the srv1 lab created
/var/lib/gunbc/materialization-store-staging(11:11Z), and compute builds launch again there.After landing
srv1 needs one sudoers reinstall carrying both new grants (this PR's and #13723's).
🤖 Generated with Claude Code