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>,<count>,<size>
.
The order of the arguments does not actually matter – they are identified based on a regex (pool names must start with a letter and sizes must end with a unit suffix).
<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.<count>
: number of volumes<size>
: size of each volume
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.<count>
: the minimum number required by the charm, or ‘1’ if the storage is optional<size>
: determined from the charm’s minimum storage size, or 1GiB if the charmed operator does not specify a minimum
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.