Host space on a shared host

A fleet host is either dedicated to the fleet or shared: a person's own computer that also runs fleet work. Its registry entry says which in targets[].ownership, dedicated or shared; an entry that declares nothing is dedicated.

  • stado fleet enroll NAME --ssh DEST --shared registers the machine as shared in the same registry write that registers it, before its agent or janitor first runs there.
  • stado fleet enroll NAME --ssh DEST --dedicated registers a machine its owner gave to the fleet with the word dedicated written, in the same write. A machine is given to the fleet by someone other than the machine itself, so --dedicated refuses the machine the command runs on: a destination whose host is localhost or a loopback address before anything is read, installed or probed, and a machine whose probed hostname is this machine's own name before anything is written (stado.fleet.registration.dedicated-self, exit 2: the machine at <ssh> is the one this command runs on, and a machine is given to the fleet by someone other than the machine itself, so it never declares itself dedicated; fix: enroll it without --dedicated, with --shared when it is a person's computer, and have whoever gives a machine to the fleet run the command from another machine). --shared and --dedicated together are refused (tests/fleet/enroll_failures/request.rs). The word is a registry word any writer of the registry can set, so it decides cleaning and nothing else: the real journeys that load units into an account's own launchd (the release and product-install journeys under tests/release and tests/product_install) run only inside a scratch lease Stado took on a registered host, read with stado scratch self, never on a word in the registry.
  • stado registry set --path targets.NAME.ownership --value shared declares an already registered host shared; --value dedicated gives it back to the fleet.

On a shared host every pass deletes only inside Stado's own tree, ~/.stado. The cleaners whose areas lie elsewhere — agent_logs, chromium_clones, compiler_cache, docker, huggingface_cache, local_snapshots and, when its declared directory is outside ~/.stado, weles_recordings — still measure and report what they would take, remove nothing, and count one skip under shared_host_not_stado_owned. The build_caches walk still sizes every CACHEDIR.TAG tree in the home, so the report keeps saying what holds the disk; it removes only a tree under ~/.stado (such as the build cache ~/.stado/build-cache) and counts each other one under shared_host_not_stado_owned. The pass does not write the account's Cargo configuration either: declaring Cargo's build directory there is its owner's choice. The cleaners whose areas are Stado's own (backup_twins, delivered_releases, job_outputs, object_evidence, queue_workdirs, release_store, the service logs under ~/.stado/logs) run as on any host.

A host whose registry entry cannot be read, or whose ownership is neither word, is cleaned as a shared host: whose files its home holds is then not known. The report's errors carries ownership: with the reason.

The real test is tests/space_reclaim/native/shared.rs: on its own APFS volume it declares the host shared through stado registry set, fills the volume past the rule, runs a pass, and checks that a tagged cache and a Hugging Face model outside ~/.stado survive and are counted under shared_host_not_stado_owned, while a tagged cache under ~/.stado is removed.

Source: this website