Repository navigation
Conversation
Let the replica-exclusion policies and the client-maintenance checks tell an armed, fixed migration worker from ordinary compute, by exact pool name and the enabled label together. No node carries that label, so nothing changes on the cluster until a later slice arms one. The admission and retrofit rules share one condition. The retrofit reads it from the live target and now mutates only its own trigger, so a compute node can never fence armed migration capacity. Part of #5655. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The malformed-label test also fenced the node, so a later check failed it and it would have stayed green without the label check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@codex review |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Evaluation at
Codex is clean at this head, CI has no failures and there are no review threads. |
Why
The Longhorn V2 migration needs temporary workers that may hold storage, while every other short-lived worker must stay free of it. Today the storage rules and the client-maintenance checks treat all of those workers alike, so a worker armed for the migration would be fenced off again, or the checks would hold. This is the first part of the third slice of the split decided on #5655.
What
An armed migration worker is now recognised only when its exact pool name and its enabled label agree, and the maintenance checks also require its reviewed pool and its scale-down protection. No worker has that label, and this change adds no way to set it, so nothing changes on the cluster. It adds no worker and no cost: the new worker and the capacity changes follow the worker layout slice, because a worker created earlier would come up with the wrong disk layout.
Part of #5655
👉 After merge/promotion: nothing to do; the migration stays dormant.