From 4d0693cb8c560e88e85d78094c73d208fe9180b6 Mon Sep 17 00:00:00 2001 From: Feng Ruohang Date: Tue, 15 Sep 2026 14:56:20 +0800 Subject: [PATCH] docs: record controlled retirement evidence and qualified upgrade runs Signed-off-by: Feng Ruohang --- .../lifecycle/access-tiering-removal.md | 2 +- docs/investigations/access-tiering-revert.md | 36 ++++++++++++++++--- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/docs/bucket/lifecycle/access-tiering-removal.md b/docs/bucket/lifecycle/access-tiering-removal.md index 7e87563da..876aecdfc 100644 --- a/docs/bucket/lifecycle/access-tiering-removal.md +++ b/docs/bucket/lifecycle/access-tiering-removal.md @@ -12,7 +12,7 @@ The published Server 20260903 predates this feature. These instructions concern 2. On the old server, set `ilm access_tiering=off` and remove or disable any access-tier environment overrides. Allow in-progress moves to finish before replacing nodes. This reduces movement intermediate states; the removal itself changes no storage RPC protocol. 3. Remove top-level `AccessTierQuota` and rule-level `AccessTransition` elements. **Delete rules whose only action was `AccessTransition`**. For a mixed rule, retain its filter, status, ID and ordinary expiration/transition actions. An access-only rule loads harmlessly after upgrade, but becomes an actionless rule and fails validation on the next lifecycle edit. If no rules remain, delete the lifecycle configuration through the S3 API. 4. Use a coordinated maintenance window: stop the deployment, install the same new binary on every node, then restart all nodes. The existing bootstrap check compares binary checksums; in a four-node test the first new node could not finish starting among three old nodes. Do not assume that an unchanged RPC protocol permits replacing one node at a time and waiting for it to become ready. This removal does not relax that check. Apply the same environment changes on every node: bootstrap also compares server environment settings, so removing an old override on only some nodes can block startup even with matching binaries. The check runs only during startup and is not a safety guarantee for nodes already running different binaries. -5. After restarting, verify object reads, bucket listing, ILM worker settings and a lifecycle edit. Complete distributed upgrade acceptance for the exact binaries before production rollout. +5. After restarting, verify object reads, bucket listing, ILM worker settings and a lifecycle edit. Check storage access from every request-serving node to each pool's drives: successful reads or bucket listing establish less than complete drive reachability, and admin disk summaries aggregate server-local state. Retirement acceptance used unique probes and storage trace to confirm every node-to-drive path before and after version deletion. Startup connection times varied, so a fixed sleep is insufficient. Complete distributed upgrade acceptance for the exact binaries before production rollout. ## What happens to stored state diff --git a/docs/investigations/access-tiering-revert.md b/docs/investigations/access-tiering-revert.md index 30f70407c..0c76b7240 100644 --- a/docs/investigations/access-tiering-revert.md +++ b/docs/investigations/access-tiering-revert.md @@ -4,7 +4,7 @@ 初稿审查时（2026-09-15 03:20 UTC），最终候选尚未移植到远端基线、尚未冻结 PR head，合并前全量检查与三次有效 Linux 运行尚未执行，本变更尚未合并。后续执行状态以承载本记录的 PR 及其绑定提交的验收记录为准；下文的历史实验不替代这些检查。 -**当前执行状态：** 回退、普通版本 DELETE 调和、扫描复用及文档已提交到 [Draft PR #188](https://github.com/pgsty/silo/pull/188)。本地与 CI 检查通过，但第二轮有效 Linux 升级实验出现 DELETE204 后的 HEAD/GET503，合并验收未通过。当前不合并、不发布，main 的五份旧修改仅归档，尚未清理。详情见第 9、10 节。 +**当前验收状态：** 回退、普通版本 DELETE 调和、扫描复用及文档由 [PR #188](https://github.com/pgsty/silo/pull/188) 交付。本地与 CI 检查通过；首次 Linux 验收因 DELETE204 后的 HEAD/GET503 停止。随后完成可控机制实验、匹配写入负载对照，并修正准备检查；独立的新轮次 R-Upgrade-2 三次完整升级验收均通过。旧失败没有改判，原单次请求的逐盘状态仍不可追溯。最终合并状态以 PR 为准，正式发布与部署另行验收。详情见第 9 至 11 节。 ## 1. 引入的目标和实际范围 @@ -154,12 +154,40 @@ Claude Code Opus 5 / max 的五轮实现评审要求补齐退役兼容、说明 Claude 撤回了此前“逐节点三轮404已是最强全池准备条件”的表述，同意这只能证明读 quorum，不能证明全盘可达或写 quorum。诊断给出了候选机制，但**第三次尝试失败瞬间没有逐请求逐盘日志，仍不足以确定其具体原因**；不能把后来稳定期的成功、诊断中的配额不足，或对错误名的解释当成该次故障的直接证据。 -## 10. 停止位置与恢复资料 +## 10. 首次执行的停止位置与恢复资料 -截至本记录交付，代码仍为 `41aa84609`；后续提交仅记录本次执行，不改变已测试的生产代码。有效升级运行是一通过、一失败，未满足三次有效运行全部通过的约定；总尝试3次，并未通过继续补跑消耗剩余次数来冲淡失败。`2059bc6b` 和先前的 `83676ca2` 均保持 **OPEN**。Claude 与 Codex 的最终裁定是 **NO-GO for merge**，不把证据不足升级为“已修复”“既有问题”或“暂态”。实际 PR 合并状态始终以 [#188](https://github.com/pgsty/silo/pull/188) 为准。 +首次执行停止时，代码为 `41aa84609`；后续提交只记录执行，不改变已测试的生产代码。当时有效升级运行是一通过、一失败，未满足三次有效运行全部通过的约定；总尝试3次，没有通过继续补跑消耗剩余次数来冲淡失败。`2059bc6b` 和先前的 `83676ca2` 均保持 **OPEN**。Claude 与 Codex 当时的裁定是 **NO-GO for merge**，没有把证据不足升级为“已修复”“既有问题”或“暂态”。后续收尾见第 11 节；实际合并状态以 [#188](https://github.com/pgsty/silo/pull/188) 为准。 -主工作区原五文件的完整内容、二进制补丁和 SHA-256 已归档；另有可达 Git 引用 `refs/archive/access-tiering-main-five-files-20260915`，指向快照 `c7fbfc6ada0f0f2abcbe8c0a9681f07e12dafe52`。逐文件核验快照与原已审内容一致。由于最终验收未通过，未执行五文件恢复，也未移动或改写独立 IAM 提交 `ebc9937d9`。这不是“三份变体已经归一”的完成声明；唯一待交付候选仍在 PR 分支，旧变体冻结等待验收裁定。 +主工作区原五文件的完整内容、二进制补丁和 SHA-256 已归档；另有可达 Git 引用 `refs/archive/access-tiering-main-five-files-20260915`，指向快照 `c7fbfc6ada0f0f2abcbe8c0a9681f07e12dafe52`。逐文件核验快照与原已审内容一致。首次停止时因验收未通过，没有执行五文件恢复，也没有移动或改写独立 IAM 提交 `ebc9937d9`。当时唯一待交付候选在 PR 分支，旧变体冻结等待验收裁定。 本机执行资料归档在 `~/.codex/outputs/silo-access-revert-assessment-20260915/final-execution/`：保存了每次尝试、旧/新基线对照、二进制 SHA-256、准备条件、源/目的全盘元数据、诊断补丁、独立评审意见，以及受控清理记录。原始失败记录不覆写；保存的诊断卷内容用于继续调查，不是生产数据或发布制品。 继续推进需要一次能区分机制的取证：在条件可控的升级实验中，于失败请求当时记录每池每盘的真实应答和错误类型，并同时读刚删版本与从未写入版本；明确区分盘面不同步、请求节点的不可用路径与其他原因。若四盘均真实应答仍返回503，应沿错误归约/元数据路径定位；若盘不可用，应查明连接或初始化状态，并验证准备条件。后续成功本身不能关闭本次失败，更不能通过把不可判定的503改成404来满足验收。正式发布、制品和生产部署继续作为独立交付。 + +## 11. 收尾复核：准备检查、可控机制与独立新轮次 + +后续收尾没有继续修改生产代码。旧基线 `89637554d` 与候选 `41aa84609` 使用各自的独立诊断构建，仅对测试桶记录逐盘应答；这些日志补丁没有进入 PR。第一轮完整诊断 `53ebe161` 通过但未复现503，仅作为一个样本保留。第二轮 `c951f762` 得到了不同的、可直接解释的失败：两个池的删除调用均记录 `quorum=3 errs=[nil,nil,nil,drive not found]`，DELETE204、所有读样本404，但八盘快照的盘3、7仍保留目标版本。它符合既有写 quorum 契约，并正向证明旧准备门会放行尚未完成挂盘的协调节点；它没有复现或解释 `2059bc6b` 那一次请求。 + +审查还纠正了两项推断：后续诊断进程在04:19的重连日志不能用于解释03:56的原失败；错误归约按具体错误值计数，不能把“最高同值计数不足”简单等同于“实际应答盘数不足”。原失败之后的全盘快照也不是失败瞬间的原子快照。这些界限继续保留。 + +准备检查改用服务器已有的 storage trace：从每个 S3 节点，对各自唯一、从未写入的对象执行 `GetObjectTagging`，该路径等待所有盘；按唯一对象名和后端节点、盘路径匹配真实 `storage.ReadVersion` 应答。四节点双池需要每轮32条实际缺失应答，连续三轮完成才满足准备条件；单纯404或 `admin info` 的本地盘状态不够。探针不创建对象，不改变服务器读写语义。trace 输出是多行 JSON 对象流，按流解析；缺失 trace 证据会使检查失败，不能据此假定对应盘健康。 + +为了比较相同的跨池写入负载，停止真实 rebalance 夹具后复制两份相同数据。旧基线使用 #178 已有的 `If-Match` 条件 DELETE，候选使用普通指定版本 DELETE，二者都处理同一目标的两个池副本。两臂分别完成96次“已删版本／从未写入版本”的 HEAD/GET 对照，均404，目标八盘均清除。准备检查分别耗时约0.60秒和17.08秒。这是一对匹配样本，没有观察到候选专属差异，不是吞吐比较，也不能排除所有可能的故障机制。 + +`f55967b7` 另用明确制造的重复副本夹具完成因果实验，而非冒充真实 rebalance：pool0 的四盘由一个节点承载并保留 namespace 锁；pool1 的四盘分布到另外四个节点。先停止 pool1 一盘，DELETE204 后直接确认只有该盘残留目标版本。重新接入这份副本，再停止 pool1 两块已删除该版本的盘，保留“一盘返回版本、一盘返回缺失”的读视图。三个被测协调节点的已删版本均返回 `503 SlowDownRead`，从未写入版本均返回404；同一失败请求的逐盘记录明确为 `[drive not found, drive not found, file version not found, nil]`，没有足够的同值应答达到读 quorum。整个实验没有丢失 pool0 的 namespace 锁，也没有将不确定状态改为404。 + +该因果实验的部分节点重启未在35秒内恢复全部40条访问路径，原实验因此仍记 FAIL；正向机制观察与这个恢复失败分开记录。随后协调重启全部五节点，独立恢复检查通过，五节点 HEAD/GET 均404。这不是滚动恢复已通过的声明，也不追溯原 `2059bc6b` 的逐盘状态。可控复现确定的是故障机制类别，原单次实例继续 **OPEN**。 + +Claude 复核上述证据后同意显式开启 **R-Upgrade-2**：原轮次的一通过、一失败和总尝试3次保持原样，不合并计数，不静默重置。新轮使用未经诊断修改的 `41aa84609` 二进制，要求三次有效运行全部通过、最多五次总尝试；任何新503或数据不变量失败仍须停止。每次 DELETE 前后均检查32条路径，响应后的即时 HEAD/GET 先于后置准备检查执行，避免等待掩盖短暂错误。 + +| 新轮次运行 | 完整运行耗时 | 升级后32路径准备耗时 | 验收结果 | +| --- | --- | --- | --- | +| `8eb016db` | 90.20秒 | 17.04秒 | PASS | +| `2a2b7b64` | 80.83秒 | 0.62秒 | PASS | +| `371e7b9f` | 96.28秒 | 0.60秒 | PASS | + +三次均实际走到候选阶段：DELETE204，所有即时及后续 HEAD/GET 样本404，目标在八盘均不存在，其他版本从四节点读回；旧配置、普通生命周期规则编辑及真实缓存 v9→v8 均通过。删除前后各三轮32路径检查也全部通过。准备时间有明显波动，应验证访问路径，不能用固定等待秒数代替检查。这些结果满足修正准备条件后的有界验收；不把有限样本写成“历史503已消失”，不把不同阶段的诊断通过计入新轮次。 + +新轮仍绑定生产代码 `41aa84609`（Linux 二进制 SHA-256 `28e1339d630a22fa5a0e4659b6182224e81f6cd7cd4079856534390e40a697b1`），后续仅更新文档。合并前须核对源码等价性和最终 CI，按第8节的恢复纪律处理旧五文件，保留独立 IAM 提交。原 `2059bc6b`／`83676ca2`、部分重启恢复边界、单 VM/tmpfs、未验证全部不同重复 UUID 和整份运行时统计守恒继续可见；不为此新增自动搬回、清理服务或读错误降级。 + +本轮详细资料位于原归档的 `final-execution/closure-20260915/`，包括匹配对照、同请求逐盘日志、`qualification-summary.json`、独立 R-Upgrade-2 账本、诊断补丁和完整卷归档。原失败现场、后续对照及恢复后的卷分别标注时点。临时实验资源在归档验证后清理；这些资料与正式发布制品区分管理。