Provisioning
Creating an object writes a configuration. It does not create anything the configuration describes. Provisioning is the step that does: allocate the disks, create the volume group and its logical volumes, format the filesystems, plumb the ip address, pull the container image.
The reverse, unprovisioning, destroys them again. That distinction matters: deleting an object removes its configuration, unprovisioning destroys its data.
Provisioners
A resource driver may implement a provisioner, and most of the drivers that
represent something allocatable do: the disk, fs, ip, volume,
container, share and app families.
A provisioner often needs keywords the resource does not need in order to run, such as a size or a pool. Those are listed with the driver in the keyword reference.
A provisioner may also write back into the configuration. Most ip provisioners
set the resource’s ipname once they know the address they obtained.
Provisioning an object
om myapp provision
This is orchestrated. The daemon provisions the placement leader first and
leaves the instance up, so that later provisioners can rely on what the
earlier ones produced: a disk must stay attached for a filesystem provisioner
to format it. Once the leader is provisioned, the other instances are
provisioned in parallel and rolled back, leaving the object in its optimal
state.
om myapp deploy does the same in one step, creating the object and
provisioning it.
To act on the local instance only, without involving the daemon:
om myapp instance provision --leader
The provisioners run in the resource start order.
--leader matters here. Driving this by hand, you are telling the agent which
node provisions the resources that only one node may provision. Without
it, the local instance is treated as a follower: its own resources are
provisioned and the shared ones are silently skipped. Pass --leader on the
node that should own them, and omit it on the others.
The orchestrated om myapp provision above works this out for you, which is
the reason to prefer it whenever the daemon is available.
Shared resources
A SAN disk visible from several nodes, or the filesystem on it, must be provisioned once, not once per node. Flag those resources:
[disk#1]
type = vg
name = datavg
shared = true
The provisioned state of a shared resource is synchronized across the object’s nodes. The state of a non-shared resource is node-affine, and each node provisions its own.
Which node provisions them is the leader question above: the orchestrator
picks the placement leader, and a manual provision needs --leader to say so.
Resources you provisioned yourself
Resources that already existed when the object was created are reported as not
provisioned, which om mon marks with a P.
Successfully starting such a resource marks it provisioned: if it starts, it is sane to consider it provisioned. When starting it is not possible or not wanted, flag it without touching the system:
om myapp instance provision --state-only --rid disk#1
This only sets the flag. Nothing is formatted, allocated or created. The flag matters because unprovision skips resources that were never provisioned, so an unflagged resource survives an unprovision that should have destroyed it.
Unprovisioning
om myapp unprovision
This destroys the resources, and it is the dangerous half of the pair. Shared resources are unprovisioned once, by the leader, in reverse order.
➡️ See Also