.. _agent-service-provisioning: Provisioning ************ Introduction ============ Services and volumes objecs handle resources activation and desactivation: disk, volumes groups, filesystems for example. Upon creation, the resources may or may not already exist. In the later case, the object can provision them, in other words the object can allocate disks and ip address, create volume groups and logical volume, format filesystems, create containers, pull docker images. This section describes: * how this provisioning feature work * how to provision and template services * some useful examples Provisioners ============ Each resource driver can implement a provisioner, but not all resources actually do. The list of drivers with provisioning keywords:: $ egrep -l "provisioning:\s*True" /template.*conf | sed -e "s@/template.service.@@" -e "s@.conf@@" | grep -v "fs\." container.esx container.kvm container.lxc container.lxd container.ovm container.srp container.vz container.xen container.zone disk.disk disk.gce disk.loop disk.lv disk.lvm disk.md disk.pool disk.rados disk.veritas disk.vg disk.vxdg disk.vxvol disk.zpool disk.zvol fs ip.amazon ip ip.crossbow ip.docker ip.gce ip.netns volume Each resource provisioner may require or support additional parameters. The resource configuration templates in ```` highlight these particular parameters with ``provisioning = True``. The list of provisioning keywords of the ``fs.xfs`` driver can thus be extracted using:: $ egrep -B 5 "provisioning:\s*True" /template.fs.xfs.conf \ | grep keyword # keyword: vg # keyword: size A provisioner can update the DEFAULT and resource configuration parameters. For example, most ip provisioners set the resource ``ipname`` parameter. Provisioning Workflow ===================== The provisioning can be either local (--local) or orchestrated. When orchestrated, the daemon starts provisioning the instance on the placement leaders. When provisioned, these instances stays ``up`` and the daemons move on to provisioning all other instances in parallel. Those are rollbacked after provisioned, so the service is in optimal state at the end of the orchestration. The CRM command run on the leader node is:: $ om provision --local --disable-rollback --leader The CRM command run on the non-leader nodes is:: $ om provision --local The provisioners are run in the start natural order. Each resource is left in the ``up`` state after its provisioning, so that the following provisioners can count on their availability to proceed. For example, a amazon allocated disk must be left attached for a fs provisioner to format it. Shared Resources ================ Shared resources (like SAN disks visible on multiple nodes, filesystems hosted on these disks, failover ip addresses), if any, must only be provisioned on the leader and not reprovisioned on the other nodes. Implementing this behaviour requires the admin to explicitely flag such resources as shared using the generic ``shared = true`` resource keyword. The provisioned state of shared resources is synchronized automatically amongst the service or volume nodes, whereas the provisioned state of local resources is node-affine. It is possible to provision all or part of the resources manually, before the service creation. In this case, those resources will be reported as unprovisioned (a ``P`` flag in the print status output). A successful resource start will mark the resource as provisioned (if it starts ok, it is sane to consider it provisioned). If starting the resource is not possible or desirable, the agent still provides a way to force the resource status as provisioned:: $ om set provisioned --rid , Or even all the local instance resources using:: $ om set provisioned Provisioning Usage ================== The provisioners are activated either by the ``provision`` and ``deploy`` action or by setting the ``--provision`` option with the following actions. Create ++++++ * ``om create --template |