Struct CloudConfig 

pub struct CloudConfig {
    pub workspace_root: PathBuf,
    pub machines: Vec<MachineConfig>,
    pub providers: Vec<ProviderConfig>,
    pub machine_origins: BTreeMap<String, InfraOrigin>,
    pub provider_origins: BTreeMap<String, InfraOrigin>,
    pub services: BTreeMap<String, ServiceWithMirrors>,
    pub domains: BTreeMap<String, DomainConfig>,
    pub legacy_mirrors: Vec<LegacyMirrorConfig>,
    pub workloads: Vec<WorkloadConfig>,
    pub topology: TopologyConfig,
    pub legacy_services: Vec<LegacyServiceConfig>,
}

All cloud config loaded from a workspace root (the parent of .yah/).

Reads two trees:

• .yah/infra/ — machines/, providers/
• .yah/services/<svc>/ — service.toml + mirrors/<env>.toml

Pre-R215 fields (legacy_mirrors, legacy_services, workloads, topology) are still populated from .yah/cloud/ when present so pre-R215 callers (compose.rs, bucket commands) keep compiling — they just see empty collections in a post-B1 workspace where the legacy data was deleted. These fields are scheduled for removal in B3-T3.

Fields

workspace_root: PathBuf

Workspace root that was loaded — useful for path-resolving component references on a ServiceComponent.

machines: Vec<MachineConfig>

.yah/infra/machines/<name>.toml

providers: Vec<ProviderConfig>

.yah/infra/providers/<id>.toml

machine_origins: BTreeMap<String, InfraOrigin>

Provenance for every entry in machines that came from a linked .yah/infra/sources.toml source rather than this camp’s own .yah/infra/machines/ (R615-F2 / W274). Keyed by MachineConfig::name; a name absent here is camp-local. Empty from CloudConfig::load_from_config_dir — see its doc for why sources don’t apply to multi-root sibling trees.

provider_origins: BTreeMap<String, InfraOrigin>

Same as machine_origins, keyed by ProviderConfig::id.

services: BTreeMap<String, ServiceWithMirrors>

.yah/services/<svc>/ — service.toml plus mirrors/.toml.

domains: BTreeMap<String, DomainConfig>

.yah/domains/<name>.toml — public-facing routing manifests (R347). Single file per domain; no nested per-env tree because domains themselves aren’t projected onto infra — they describe how a Worker bundle ingresses requests onto services.

legacy_mirrors: Vec<LegacyMirrorConfig>

Legacy mirrors from .yah/cloud/mirrors/.

workloads: Vec<WorkloadConfig>

Workloads from .yah/cloud/workloads/*.toml (R092-F1 schema).

topology: TopologyConfig

Topology from .yah/cloud/topology.toml (mirror→machine assignments).

legacy_services: Vec<LegacyServiceConfig>

Legacy services from .yah/cloud/services/*.toml (pre-R092 layout).

Implementations

impl CloudConfig

pub fn load(workspace_root: &Path) -> Result<Self>

Load all cloud config rooted at workspace_root (the parent of .yah/).

Reads the R215+ tree (.yah/infra/, .yah/services/<svc>/) eagerly and the pre-R215 .yah/cloud/ tree opportunistically. Returns Err immediately if any TOML fails to parse or a workload TOML fails shape validation; the error includes the file path and field path.

Cross-ref validation runs after both trees finish loading: every mirror.providers.X.use = "<id>" must resolve to a real provider declared under .yah/infra/providers/.

pub fn load_from_config_dir( config_dir: &Path, workspace_root: &Path, ) -> Result<Self>

Load the R215+ tree (infra/, services/, domains/) rooted at an arbitrary config directory instead of the hardcoded .yah/. This is the building block for multi-root deployments (W206 config layout (b), sibling .noisetable/ trees) — see crate::multi_root. Part of R558-F4.

config_dir is the .X/ directory itself (e.g. <parent>/.noisetable); workspace_root remains the camp dir (the config dir’s parent) so a component’s path reference resolves against the same tree the classic CloudConfig::load uses. The legacy .yah/cloud/ reads are skipped — multi-root deployments are post-R215 by construction — so legacy_*, workloads, and topology come back empty. Machines are read from config_dir/infra/machines directly (sibling trees declare their own inventory or none).

R615-F2 decision, explicit rather than silent: sources.toml overlay does NOT apply here. This function exists specifically because a multi-root sibling tree (W206 layout (b), e.g. .noisetable/) is a second config root inside the same camp, not a second camp — config_dir is already wherever the caller decided this tree’s infra lives, and .yah/infra/sources.toml (singular, tied to paths::infra_dir(workspace_root)) has no well-defined meaning for an arbitrary config_dir that isn’t that path. A sibling tree that wants borrowed infra declares its own sources.toml under whichever root actually calls CloudConfig::load for it; machine_origins/provider_origins come back empty here, not wrong — there is nothing to overlay.

pub fn domain(&self, name: &str) -> Option<&DomainConfig>

Look up a domain manifest by name (file stem under .yah/domains/).

pub fn machine(&self, name: &str) -> Option<&MachineConfig>

pub fn provider(&self, id: &str) -> Option<&ProviderConfig>

Look up a provider by id (matches provider.id, not the file stem).

pub fn service(&self, name: &str) -> Option<&ServiceWithMirrors>

Look up a service by name (matches service.toml’s name field).

pub fn legacy_mirror(&self, camp: &str) -> Option<&LegacyMirrorConfig>

Look up a legacy mirror by camp name (pre-R215 .yah/cloud/mirrors/).

pub fn workload(&self, name: &str) -> Option<&WorkloadConfig>

pub fn resolve_machine(&self, req: &RequiredSpec) -> Result<&MachineConfig>

F16 placement v1: the first machine satisfying every hard axis of req (region/zone/provider membership + mesh_tags superset). Declaration order in .yah/infra/machines/ decides ties — deterministic-greedy, no backtracking. A fully-unconstrained req matches the first machine.

Fails loud with the constraint summary and the candidate machine names when nothing matches, so yah cloud apply surfaces why placement failed instead of a silent empty set.

pub fn resolve_machine_by_mesh_tags( &self, required: &[String], ) -> Option<&MachineConfig>

F16 placement: first machine whose mesh_tags is a superset of required. Declaration order in .yah/infra/machines/ decides ties. Empty required matches the first machine; callers should treat empty-required as “no constraint” and skip this lookup.

Back-compat thin wrapper over CloudConfig::resolve_machine for the mesh-tags-only call sites that predate the topology axes.

pub fn admit_workload(&self, ws: &WorkloadSpec) -> Result<&MachineConfig>

Admission: resolve the target machine for a remote WorkloadSpec, honoring the R594 mesh-tag node-selector annotation (velveteen_exec::remote::NODE_SELECTOR_MESH_TAGS_ANNOTATION = yah.node-selector.mesh-tags, comma-joined).

The producer side (velveteen_exec::remote::build_workload_spec, R594) writes TaskLocation::RemoteAny.mesh_tags — e.g. [tag:build-worker, tier:x86] from [qed::platform::build_worker_mesh_tags] — into the workload’s annotations. This is the consumer: candidates are restricted to machines whose mesh_tags are a superset of the requested set, so an amd64 build lands on the tier:x86 build-worker (us-west-002) and an arm64 build on a tier:arm Pi5. Declaration order in .yah/infra/machines/ breaks ties.

An absent or empty annotation means “no mesh-tag constraint” — pre-R594 behavior (any node), matching RequiredSpec::is_unconstrained.

This is the single admission seam: R572-F5 extends it with the capacity floor (workload request fits node allocatable−committed) and repel-unless-tolerate taints by enriching RequiredSpec::matches / Self::resolve_machine. Do not fork a second selector.

Trait Implementations

impl Debug for CloudConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.