Repository navigation
Remove the substrate version label from the install - #1812
Merged
Dmitry Berkovich (dberkov) merged 1 commit intoOct 13, 2026
Merged
Dmitry Berkovich (dberkov) merged 1 commit into
Dmitry Berkovich (dberkov) merged 1 commit into
Conversation
Haven Xia (HavenXia)
added
DO NOT MERGE
Haven Xia (HavenXia)
force-pushed
the
remove-version-label
branch
from
September 23, 2026 18:10
967b5a1 to
a5ec7e4
Compare
Merged
Bowei Du (bowei)
added
the
kind/cleanup
Haven Xia (HavenXia)
changed the title
Haven Xia (HavenXia)
force-pushed
the
remove-version-label
branch
from
October 12, 2026 18:25
a5ec7e4 to
2bac536
Compare
Collaborator
|
Since this is breaking for anyone coming from v0.4, could we add the |
Collaborator
Anna Pendleton (annapendleton)
approved these changes
Oct 12, 2026
Anna Pendleton (annapendleton)
approved these changes
Oct 12, 2026
Member
Author
Yes they will be merged at the same moment. #1844's table says upgrade cross major version is not supported, which matches our designed compatibility policy now. |
Haven Xia (HavenXia)
force-pushed
the
remove-version-label
branch
from
October 13, 2026 00:57
2bac536 to
bd4c75f
Compare
The install labeled every node with ate.dev/substrate-version, named the atelet DaemonSet atelet-<version suffix> and pinned it to nodes carrying its version. This let two substrate versions run side by side on disjoint sets of nodes, which the clone-WorkerPool upgrade runbook relied on. The GA upgrade does not split nodes by version. atelet rolls in place and worker pools roll as ordinary Deployment updates. The label breaks that flow: deploying a new atelet creates a second DaemonSet pinned to a version no node carries, so it schedules nowhere.
Haven Xia (HavenXia)
force-pushed
the
remove-version-label
branch
from
October 13, 2026 18:41
bd4c75f to
ee7a832
Compare
Dmitry Berkovich (dberkov)
approved these changes
Oct 13, 2026
Adhita Selvaraj (swiftdiaries)
pushed a commit
to swiftdiaries/substrate
that referenced
this pull request
Oct 14, 2026
Rewrites the upgrade runbook for an `in-place` roll by K8s deployment. Each component is upgraded where it runs, in order: podcertificate-controller, atelet, the workers, ate-api-server, the CRDs and ate-controller, atenet, then the default SandboxConfig. ate-controller follows the API server because it is a client of it, and new workers start from the pod template the old ate-controller renders. The old runbook ran the old and new dataplane side by side instead. This deliberately gives up two things the old runbook had. The first is zero loss. Workers are replaced through the eviction path: `SIGTERM`, then 30 minutes for the actor to be suspended before `SIGKILL`. Actors already need to handle this for node upgrades and preemption. An actor that is suspended in time loses nothing. One that isn't crashes and loses the work since its last snapshot. The old runbook avoided this by having the operator suspend every actor on a node before moving it. The second is instant rollback. Rollback is the same roll in reverse, from the old release, instead of flipping a node label back. Keeping both versions running needs spare capacity and the version label. ## TODOs Some places are marked TODO because they depend on unfinished work: 1. [DONE] The install record `ate-setup` writes (agent-substrate#1887, implemented in agent-substrate#2223) 2. The compatibility policy and the version skew policy. The runbook links both, while both poclies are still in design. 3. Per-release SandboxConfig names > Part of agent-substrate#1686 Merges together with agent-substrate#1812
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
4 participants
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.
ate-setupno longer labels nodes withate.dev/substrate-version. The atelet DaemonSet is now namedateletand runs on every node, instead ofatelet-<version suffix>pinned to nodes carrying its version.The label let two Substrate versions run side by side on disjoint sets of nodes, which the clone-WorkerPool upgrade runbook relied on. The GA upgrade doesn't split nodes by version: atelet rolls in place and worker pools roll as ordinary Deployment updates. With the label, deploying a new atelet creates a second DaemonSet pinned to a version no node carries, so it schedules nowhere.
This merges together with #1844, which replaces the label-based runbook in
docs/upgrade.md.Breaking change
Due to the removal of version label system. An install from v0.4 or earlier can't be upgraded in place. Reinstall it, as with every pre-GA minor release.
Part of #1686