Backend behaviour for lifecycle-managed HostKit instances.
A backend owns the compute boundary lifecycle for an HostKit.Instance.
HostKit keeps the user DSL generic (instance, backend, image, kind,
lifecycle, expose) and delegates backend-specific lifecycle operations to
this behaviour.
Callback responsibilities:
read/2inspects whether the declared instance exists and returns the observed instance ornil.apply/2makes the instance available for nested content application. For a VM/container backend this usually means create if missing, configure exposed ports, start, and wait until the instance can accept operations.delete/2destroys the instance when a down plan includes an ephemeral instance delete.
Backend options are stored on HostKit.Instance.backend_config by the DSL:
instance :demo do
backend :incus, sudo: true, project: "hostkit"
endBackends should emit %HostKit.Apply.Event{} progress through HostKit's
apply event emitter when applying long-running lifecycle operations.
Summary
Callbacks
@callback apply( HostKit.Instance.t(), keyword() ) :: :ok | {:error, term()}
@callback delete( HostKit.Instance.t(), keyword() ) :: :ok | {:error, term()}
@callback read( HostKit.Instance.t(), keyword() ) :: {:ok, HostKit.Instance.t() | nil} | {:error, term()}
Functions
@spec apply( HostKit.Instance.t(), keyword() ) :: :ok | {:error, term()}
@spec delete( HostKit.Instance.t(), keyword() ) :: :ok | {:error, term()}
@spec read( HostKit.Instance.t(), keyword() ) :: {:ok, HostKit.Instance.t() | nil} | {:error, term()}