Storage constraint (directive)
Storage > Storage constraint
In Juju, a storage constraint is a collection of storage specifications that can be passed as a positional argument to some commands (
add-storage) or as the argument to the
--storage option of other commands (
refresh) to dictate how storage is allocated.
A storage constraint is slightly different from a constraint – while the general meaning is similar, the syntax is quite different. For this reason, a storage constraint is sometimes also called a storage directive.
This constraint has the form
<label> is a string taken from the charmed operator itself. It encapsulates a specific storage option/feature. Sometimes it is also called a store.
The values are as follows:
<pool>: the storage pool. See Storage pool.
<size>: size of each volume
<count>: number of volumes
If at least one constraint is specified the following default values come into effect:
<pool>: the default storage pool. See How to view the default storage pool.
<size>: determined from the charm’s minimum storage size, or 1GiB if the charmed operator does not specify a minimum
<count>: the minimum number required by the charm, or ‘1’ if the storage is optional
Expand to see an example of a partial specification and its fully-specified equivalent
Suppose you want to deploy PostgreSQL with one instance (count) of 100GiB, via the charm’s ‘pgdata’ storage label, using the default storage pool:
juju deploy postgresql --storage pgdata=100G
Assuming an AWS model, where the default storage pool is
ebs, this is equivalent to:
juju deploy postgresql --storage pgdata=ebs,100G,1
In the absence of any storage specification, the storage will be put on the root filesystem (
--storage may be specified multiple times, to support multiple charm labels.
Last updated a month ago.