Storage constraint (directive)

doc
1

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.

2
3
4

Hi all,

I have a question regardning using the lxd storage provider, I have juju client installed in a container with manually added lxd cloud as described in this thread:

Right now I would like to deploy openstack from the zed charm, everything seems to work fine except for ceph-osd, I know that I have to use vm instead of container but I have problems adding more block devices:

root@juju-client:~/opens# juju list-storage --volume
No storage to display.
root@juju-client:~/opens# juju model-config | grep storage
storage-default-block-source       model    remote
storage-default-filesystem-source  model    lxd
root@juju-client:~/opens# j model-config storage-default-block-source=lxd
root@juju-client:~/opens# juju add-storage ceph-osd/1 osd-devices=64G,1
added storage osd-devices/2 to ceph-osd/1
root@juju-client:~/opens# juju list-storage --volume
Machine  Unit        Storage ID     Volume ID  Provider ID  Device  Size  State    Message
3        ceph-osd/1  osd-devices/2  3/2                                   pending  creating volume: could not create block file: allocating loop backing file "/var/lib/juju/storage/loop/volume-3-2": fallocate: fallocate failed: No space left on device: exit status 1
root@juju-client:~/opens# juju detach-storage osd-devices/2
detaching osd-devices/2
root@juju-client:~/opens# juju remove-storage osd-devices/2
removing osd-devices/2
root@juju-client:~/opens# juju add-storage ceph-osd/1 osd-devices=remote,64G,1
failed to add storage "osd-devices" to ceph-osd/1: adding "osd-devices" storage to ceph-osd/1: pool "remote" not found
root@juju-client:~/opens# juju add-storage ceph-osd/1 osd-devices=lxd,64G,1
failed to add storage "osd-devices" to ceph-osd/1: adding "osd-devices" storage to ceph-osd/1: "lxd" provider does not support "block" storage

Is there any way I can use a particular pool from my lxd cloud?

lxc storage ls
 +--------+--------+-------------+---------+---------+
|  NAME  | DRIVER | DESCRIPTION | USED BY |  STATE  |
+--------+--------+-------------+---------+---------+
| local  | zfs    |             | 18      | CREATED |
+--------+--------+-------------+---------+---------+
| remote | ceph   |             | 48      | CREATED |
+--------+--------+-------------+---------+---------+

In particular I would like to use the latter pool - remote which has 90% of my free space. Could you add some hints to the documentation? Thank you for any help

P.S - I am tagging @tlm in regard to the thread mentioned at the beginning, maybe you figured it out, how to interact with the cloud in case of juju-client being run from container :slight_smile:

5

The order of arguments in the constraint should be:

<label>=<pool>,<count>,<size>

Or for completeness, the full format is, as described in juju add-storage --help / https://juju.is/docs/juju/juju-add-storage :

<label>[=
    <pool>[,<count>][,<size>] |
    <count>[,<size>] |
    <size>
]
6

Thanks for bringing this up! All the examples I can see seem to assume the order mentioned in this doc: <label>=<pool>,<size>,<count>. However, I can see how that contradicts what’s in the other doc. I’ll check to see which one is correct and then update the docs accordingly.

1 Like