Storage > Storage constraint
See also: How to manage storage,
juju deploy,juju add-storage,juju refresh
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 (deploy, 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.
To put together a storage constraint, you need information from both the charm and the storage provider / storage pool.
This constraint has the form <label>=<pool>,<size>,<count>.
<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 (rootfs).
--storage may be specified multiple times, to support multiple charm labels.