A driver acts on the boundary between Artemis core and a given provisioning service. By implementing basic methods like "inspect VM" or "release resources", provides necessary level of polymorphism, allowing Artemis to switch transparently between pools as needed.
Capabilities are features whose support is built-in into the driver. The support is usually optional, and the feature may be disabled, but it is not possible to enable feature driver does not support.
supports-snapshots: the driver can handle snapshots of some kind.
supports-spot-instances: the driver can handle spot instance requests.
supports-native-post-install-script: the driver can handle the post-installation script on its own. Artemis core will execute the script in the preparation stage for drivers that do no have this capability.
A guest request can specify various HW constraints the provisioned machines must satisfy. For example, a desired number of CPU cores or a minimal root disk size. These constraints are eventually used by drivers to find - or create - suitable guests. Unfortunately, not all drivers are capable of handling all possible HW requirements, limitations may apply.
|yes *||no||yes||no||yes *|
|yes *||no||no||no||yes *|
|yes *||no||yes *||no||yes *|
|yes *||no||yes *||no||yes *|
|partial See #1. *||no||partial See #1.||no||partial See #1.|
disksupports only 1 item.
Term "flavor" represents one half of a template for a future guest. Flavors track various attributes that affect the virtual "hardware" of the final machine backing the guest. For example, number of processors, RAM size, or CPU family.
Term "image" represents the second half of a template for a future guest. Images holds the content of the future virtual machine, file system with installed software, kernel, configuration and so on. There are also less visible attributes tracked by pools, e.g. whether an image supports UEFI or not.
Together, flavors and images play crucial role in provisioning process, because the set of flavors and and the set of images represent various guest configurations a pool can deliver, and based on this information pools allocate actual cloud resources for a given request. It is up to maintainers to setup pools and pools' flavors and images to provide the tiers of service most suited for their workflow.
Pool drivers that work with flavors and images must keep track of known objects and their properties, This data must be kept up-to-date and reflect any kind of changes made by provisioning services backing their respective pools. For that purpose, drivers query their backend’s APIs periodically, to download the current state of objects available to them. This process is automated, controlled by Artemis core, and the gathered information is cached.
Information pool tracks for all available flavors can be modified through configuration, using the
custom-flavors directives. Each patch is applied to flavor or flavors matching given name (or regular expression), and overrides whatever the pool driver was able to collect from sources available to it in runtime.
Both directives share the same syntax, but their scope is slightly different:
custom-flavorsadds new flavors that do not exist as far as pool knows. For example, OpenStack driver can fetch list of existing flavors,
custom-flavorsthen allows maintainer to create additional flavors on top of this basic list.
patch-flavorsmodifies existing information known to pool, and does apply to flavors both real and created by
Information pool tracks for all available images can be modified through configuration, using the
patch-images directive. Each patch is applied to image or images matching given name (or regular expression), and overrides whatever the pool driver was able to collect from sources available to it in runtime.
The most up-to-date information on known flavors and images can be displayed by querying API:
$ http https://$hostname/_cache/pools/$poolname/image-info $ http https://$hostname/_cache/pools/$poolname/flavor-info
It is also possible to trigger refresh of stored data with
POST method, with no data:
$ http POST https://$hostname/_cache/pools/$poolname/image-info $ http POST https://$hostname/_cache/pools/$poolname/flavor-info
Besides the operational logs related to guest provisioning, drivers often expose additional logs, usually related to the provisioning service actions or guest VM operations (terminal or console, output of
The actual list of logs supported by a pool depends on the driver - this is a hard limit, logs that driver does not support cannot be "enabled" - and pool configuration, where maintainers can disable particular logs on purpose.
Each pool can tune down the supported set of guest logs: while it is not possible to enable logs that are not already supported by pool’s driver, it is still possible to disable supported logs, preventing users from accessing them.
Pools can be marked as available only when requested by name, via
environment.pool field of the request. Such a pool would be ignored by the routing when processing requests that did not request the particular pool, making it effectively invisible for more relaxed requests.