A standby

A standby

stado placement standby PROFILE --host HOST --reason WHY makes a registered host a place the profile may move to, as one idempotent pass: each service of the profile is resolved through the service catalog — by its own name, else by the unit the placed host's template declares for it (its name, then its launchd label or systemd unit), since a directory service named for what it offers often runs a product the catalog names otherwise — and classified by its program — a managed program under $HOME/.stado/bin is delivered through the same manifest-verified path stado release version converge uses, at the version the host or the placed host declares under managed_versions; a release-controlled tree under $HOME/.stado/services/<product>/current is declared for the host in the release control of that product, or of the product whose service names it (weles-worker rolls out weles-admission) — an install_root written as an absolute path under the placed host's home is rewritten in the same commit to that path under {home} (for a host release control already targets, in a commit of its own), which each host expands to its own home, and a root under neither is refused, since the new host would install into a path not its own; when the root is not {home}/.stado/services/<product> itself, where the catalog program runs from, or when the product's release control rolls it out with the replace strategy (the release agent drives only blue-green policies, and a replace release reaches a target only when it is promoted, so no agent pass would ever stage it), the pass also installs the desired release there (fetched and verified against its signed manifest as the release agent does, unpacked by the archive installer stado service release uses, current moved onto it, the catalog program required in it; a tree already active from that archive is left as it is), reporting delivered, since the agent's rollout would leave the staged unit's program missing — under the $HOME the host's own shell states (read over its channel; a host that does not state one is refused as unreachable), and the host's own agent stages it — then every unit is asserted through service ensure from the catalog for the host's platform, and only when every unit is declared is the host written into the profile and into the directory as a standby endpoint. Its probes are the placed host's, each asking the port its unit listens on on this host — the address the directory names for the host, else the placed host's port, which the unit then takes — so a host the directory already serves on another port is probed where it listens; a probe of a service the directory does not route is copied as it is, and a probe URL that cannot carry a port is refused by name. Before each unit is staged, the host's socket table is read for the port the directory gives it there; the staged unit is not running, so any listener is another program, and the pass is refused with <host>: the service directory gives <service> (<catalog>) port <port> there, and pid <pid> (<command> as <user>) already listens on it; the moved unit could not bind it. Give <service> a free port on <host> in the directory's standby address, or move the other program off it, then stand by again. The host said: …. Writing the host into the directory advances service_directory.generation with it: every resolver refuses a directory changed under the generation it holds, and a registry write that would do that is refused before the store sees it. A pass that stops at a pending rollout reports awaiting_release_rollout; the next pass continues. Refusals name the cause: an unknown profile, the placed host standing by for itself, a service the catalog does not know, a program neither delivery path reaches, a product with no artifact for the host's platform (and the submit that would build one), a version nobody declares. --check gives the refusals the pass gives before it delivers anything — no reason, an unknown profile or one a move holds, the placed host standing by for itself, a service the catalog does not know, a program neither delivery path reaches — and lists what it would deliver ({"status": "would_stand_by", "profile", "host", "placed_on", "platform", "services": [{"service", "catalog", "delivery": "managed_program"|"release_tree", "product", "release_control", "as_daemon"}]} with --json, release_control naming, for a tree, the release-control product that rolls it out and its install_root, or null when none does; the text form prints one line per service, <host> <service> <delivery> <product> <release-control product> with not reported for a field the check has none for, then <profile> <host> would_stand_by), delivering, staging and writing nothing; artifact and version refusals come only from the delivery itself. Each step of the pass is a wait on stderr, czekam: placement standby of <profile> on <host>: deliver <service>, … stage unit <service> and … write the host into the profile and the directory (on the registry), closed with its time or its cause, so a pass that stands names its step in stado waits and in Stado Desktop's open waits. Every managed program of the profile is delivered at once, each over the host's own channel; release-controlled trees are declared one after another, since each is a compare-and-swapped registry commit. The receipt lists the deliveries in the profile's order, and the first refusal in that order is the one reported.