pub struct FloatingIpMachine {
pub name: String,
pub provider: String,
pub location: Option<String>,
pub region: Option<String>,
pub ingress_floating_ip: Option<String>,
}Expand description
The machine facts floating-IP mobility actually needs — the whole contract between this crate and whatever declares machines.
Five fields because five is what the vendor adapters read. Keeping it a
value type rather than borrowing cloud’s MachineConfig is the thing that
lets yubaba link this crate: a fleet node has no .yah/infra/machines/
tree and could not build a MachineConfig if it wanted to, but it can name
a machine and say which provider hosts it.
Fields§
§name: StringDeclared machine name. Every adapter’s resolve_target looks the box up
by this: Hetzner ?name=, Vultr ?label=, OVH serviceName.
provider: StringProvider id — "hetzner", "ovh", "vultr". Selects the adapter.
location: Option<String>Provider DC code. None for static nodes.
region: Option<String>Coarser provider region, used by OVH when location is absent.
ingress_floating_ip: Option<String>Which floating/reserved IP follows public ingress onto this machine.
None is the common case and a supported shape: a fleet whose ingress
moves by DNS alone has no floating IP anywhere.