storage ng #2
Description
Generic storage charm subordinate. Intended to aid in making charms easier to interface with external storage solutions without having to speak and understand each type. Presents a single mount point on the unit, and communicates that back to your service through the data relation. This charm is a fork of storage, and is a total rewrite in python to make unit testing and quality easier to enforce.
- Tags:
- file-servers ›
Subordinate Storage Charm
This charm aims to allow storage to be mounted and consumed in your juju environment. Simply attach this charm to any that supports the "block-storage" interface, and the charmed application will start writing data into the provided storage.
General idea
The storage charm is a subordinate charm that you attach to a main charm in need of block storage space on one side (using a scope:container relation), and to a storage provider on the other side (using a normal relation).
You need to explicitly configure what provider to use in the subordinate configuration, using the aptly named "provider" config variable.
Example usage
The following will try to give you an idea of typical usage, using NFS as an example:
juju bootstrap juju deploy my-main-service juju deploy storage # this charm juju deploy some-charm-exposing-nfs juju set storage "provider=nfs" juju add-relation nfs storage juju add-relation storage my-main-service
The charm in need of storage should send a "mountpoint=/where/I/need/space" message to the storage subordinate using a "set-relation" call:
// data-relation-changed on my-main-service set-relation "mountpoint=/please/mount/here"
Once the storage is ready, the subordinate will also set-relation, so you can test whether the mountpoint is ready by checking "get-relation" on the same hook Since the subordinate will set-relation, the "relation-changed" hook will fire again:
// data-relation-changed on my-main-service ready = $(get-relation "mountpoint") if $ready == "/please/mount/here": do something with the mount point else: exit(0) # we'll get called later, when it's ready.
On the storage-provider side of the relation, the relevant "relation changed" hook will be called once the mountpoint has been requested, and, once it is available, the provider will send the relation-set "mountpoint=/please/mount/here" message back to the main charm.
Provider-Specific Features
NOTE:
This charm has a dependency on provider-specific metadata (like instance id).
If using the "block-storage-broker" relation to mount stroage from the cloud, you will
be limited to:
- Amazon Web Services
- Openstack
Other cloud providers are planned for the future, and patches are certainly welcome.
NOTE2:
If using this charm to mount filesystems over NFS, provider-specific limitations
do not exist.
Sample Deployment
juju deploy <principal charm>
juju deploy storage --config <my_storage_config.yaml>
juju add-relation <principal_charm> storage
Sample Data Relation
The Storage charm is designed to make your life easier as a charm author. Implementing the data relation is very straightforward.
Sample Metadata:
data:
interface: block-storage
scope: container
optional: true
Sample Joined Hook:
#!/bin/bash
relation-set mountpoint=/mnt/mydata
Sample Changed Hook:
#!/bin/bash
mount=`relation-get mountpoint`
if [ -z "$mount" ] ; then
juju-log "wait for related service to start"
exit 0
fi
service my_service stop
change_my_service_to_use_mount $mount
service my_service start
TODO
- Support other providers
- Support relating to other charms via mount, ceph-client, etc.
- Support config changes?
Configuration
- provider
- (string) The backend storage provider. Will be mounted at root, and can be one of, local, block-storage-broker or nfs. If you set to block-storage-broker, you should provide a suitable value for volume_size.
- local
- root
- (string) The root path where external directories will be mounted.
- /srv/data
- volume_map
- (string) YAML map as e.g. "{postgres/0: vol-0000010, postgres/1: vol-0000016}". A service unit to specific block storage volume-id that should be attached to each unit. This requires that provider is set to block-storage-broker and that volume-ids specified match a listing from nova volume-list. If a related unit does not have a volume-id specified, a new volume of volume_size will be created for that unit.
- volume_size
- (int) The volume size in GB to request from the block-storage-broker.
- 5