Evacuating a host
Evacuating a host
stado placement evacuate --from-host A --to-host B --reason WHY [--vault-owner-uid UID] [--authority] [--standby] [--profile-fixed-routes] [--repin-schedules] [--drop-release-targets] [--portable-roots] [--check] [--json] empties A
onto B.
It first checks every step — the fleet vault (stado credentials vault move --to B --owner-uid UID without --apply, whose placement check must pass),
every profile's move preflight, every role of the host Stado process (stado placement role move --check), and with --authority the registry authority
(stado placement move --authority --to-host B --check) — and one refusal
refuses the whole evacuation before anything is claimed or fenced
(evacuating A to B would be refused, so nothing was moved: <name>: <cause>; …). The profile that carries skarbiec moves only through the vault move,
which rotates the owner to a key B holds first; without --vault-owner-uid
it is a refusal that says so. --authority runs on B, the host that takes
the role, and is refused anywhere else. A registry authority that does not
answer B commits no write, so every move would stand on it: the run then
takes the authority on B first (the promotion stado placement move --authority makes of B's own copy, handed to every host) and checks and
makes every other step through B; a refusal after that says so only the registry authority, which did not answer, was taken on B, and a stop names
it among what moved. --check cannot read the registry through a silent
authority, so it refuses: the registry authority does not answer (<cause>), so no step can be checked through it; run the evacuation without --check to take the authority on B first and check every other step through B. When
B's registry store is the fleet object API and the silent authority's host
serves a role of the host Stado process, a takeover could not write that
store, so both the check and the run refuse before anything is promoted:
the registry authority A does not answer (<cause>) and also serves <roles>, the store a new authority would write, so neither can move without it; evacuate while A answers. The
room each check measures is that one profile's or role's states, not the sum
of all of them. Then the steps run
in order, each from the registry the step before it committed: the vault, the
profiles in the registry's order, the roles (each with WHY recorded in its
write fence), and the authority last, so the new authority reads a store it
holds. When A is the authority and holds a role, the role's store holds the
registry, so no commit could land once it is fenced: the first role moves
carrying the authority (role move --with-authority, checked so as well),
its receipt's authority is the evacuation's, and no separate authority step
runs. A step that fails stops the evacuation, and the error names it: the evacuation of A stopped; moved to B before it: <names>; still on A: <names>; the same command run again reads what still stands on A and moves only that
— every step reads the registry as the step before it left it, so a rerun
resumes rather than repeats. A failure in the read-back below, the schedule
repin or the release-target drop carries the same sentence. As each step
of the run starts it prints one line on stderr (evacuate: preparing <profile> for B: …, evacuate: standing B by for <profile>: …, evacuate: moving the fleet vault to B, …, evacuate: moving <profile> to B,
evacuate: moving <role>, a role of the host Stado process, to B,
evacuate: taking the registry authority on B, evacuate: stopping release control from releasing <product> to A), so a run that stands for minutes
says which step it stands on; --json keeps stdout to the report. After
each step that moves something — the install roots, the vault, a profile, a
role, the authority — the run waits until this host's resolver holds the
registry the authority now serves (stado resolver follow's wait without
--generation: the store version the authority answers), so the next step
reaches what moved where it now runs; a host with no running resolver reads
the authority itself and is not waited on. A resolver that answers without
it stops the run with its own words (this host's resolver did not follow registry store version <V>: <cause>, and <what> itself moved to B; the run stopped before the next step).
Once every step answered, the evacuation reads the registry again and is
refused, not reported, when it still places a profile or a role on A, or
(with --authority) names another host as authority: every step of the evacuation of A answered, but the registry still places <what> there; stado placement holds A shows it.
Fixed routes active on A stay there: <service> stays on A: it is a fixed route with no placement profile; give it one with stado placement profile draft, or evacuate with --profile-fixed-routes. With
--profile-fixed-routes, each fixed route on A that is not a role of the
host Stado process is first given the profile placement profile draft <service> --service <service> prints (the unit from A's declaration, the
catalog's probe and stores) and declared, before what stands on A is read,
so the run moves it like any other profile (with --standby, standing B
by for it); a route the draft refuses stays, <service> stays on A: the profile draft refused it: <cause>. With --check the profiles are drafted,
not declared, and listed as drafted_profiles ({service, profile} each;
undrafted_routes holds the refused as {service, refused}); their moves
are checked by the run once declared. A profile whose
placement cannot be told stays too, named with its cause. With --standby,
a profile that needs preparing — it lacks a store the catalog declares for
its products, or B does not fully stand by for it (it does not name B,
or names it while a unit file it declares there is missing on B) — is
prepared first, the profile carrying the vault included: before the vault or
anything else moves, the run gives it the stores it lacks (as profile sync does), runs the pass of stado placement standby <profile> --host B --reason WHY when B does not fully stand by, and then its move
preflight, and a refusal of any stops the evacuation with nothing moved — so
does a pass that ends awaiting_release_rollout (placement standby of <profile> on B ended awaiting_release_rollout: <detail>; run the evacuation again once it has); the check runs placement standby --check for the
profiles B does not fully stand by for, instead of their move preflight
(and, for the vault's profile, instead of the vault move's check, which the
run makes once they are prepared): its refusal refuses the evacuation
(<profile>: standing B by: <cause>), and its report is listed under the
profile as needs_preparing with the stores it would add (adds_stores)
and that check as standby (null for a profile that only lacks stores).
Without --standby such a profile is a refusal that names profile sync or placement standby. With --check nothing
is claimed, fenced or moved. With --repin-schedules, the schedules pinned
to A (which would keep firing there) are read before anything moves, a
schedule store that does not answer being one more refusal, and once A is
verified empty each is pinned to B through the store's compare-and-swap
edit, so a schedule changed meanwhile is never overwritten and one pinned
elsewhere meanwhile is left; a store failure there names the schedules
repinned before it. With --drop-release-targets, each release-control
product that rolls out to A stops being released there once A is
verified empty, each through the write stado release policy target remove <product> --target A makes; a product whose only target is A is refused
before anything moves, naming stado release policy remove (unless the run
stands B by for a profile running the product's service, as standby makes
B a target first); when the product's route stays on A because
--profile-fixed-routes could not draft its profile, the refusal adds or move its route: it stays on A because --profile-fixed-routes could not draft its profile: <the draft's cause>, which is what moves it. A failed write
names the products dropped before it. --json prints
{"status": "would_evacuate"|"evacuated", "from_host", "to_host", "vault", "profiles": […], "roles": […], "verified_emptied", "repinned_schedules", "release_targets_dropped", "authority", "fixed_routes", "drafted_profiles", "undrafted_routes", "untold_profiles"}, each step's check or receipt
(release_targets_dropped names the products under --check and holds each
write's receipt after the run), verified_emptied true once the run read
the registry again and found nothing standing on A. It is refused when
A and B are the same host and when nothing is placed on A, nothing is
drafted and none of --authority, --repin-schedules and
--drop-release-targets is given (that refusal names the fixed routes
there; with any of them an emptied A still has its authority, schedules or
release targets handed over, and an authority B already holds is reported
as already_authority). Before anything moves it also refuses each
release-controlled product whose install root is written under another
target's home while B is its target, since B's agent would install it
outside its own home (`release-controlled product
installs every target
at
, or give --portable-roots`); a product of a profile the run stands `B` by is not refused, since the standby writes its root under `{home}` itself. With `--portable-roots` those roots are not refused: the run writes each one under `{home}` first (`evacuate: writing
's install root under each target's home, so B installs it under its own`, through `release policy root repair`), and the report's `portable_roots` lists the products a check would rewrite or the receipts of the run. The text form ends with `the registry places no profile and no role of the host Stado process on A now`. Stado Desktop runs both forms, with `--standby`, `--profile-fixed-routes`, `--repin-schedules`, `--drop-release-targets` and `--portable-roots` as choices.
Source: this website