storage

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.

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.

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

store_encryption_keys: (string) If the volume is encrypted, this will write the details to disk to allow auto-mounting.; yes
encryption_key_map: (string) YAML map as e.g. "{postgres/0: password, postgres/1: password2}" If set, the unit's volume will be encrypted with the matching key (unless the volume is already formatted)
provider: (string) The backend storage provider. Will be mounted at root, and can be one of, local, block-storage-broker, nfs or partition. If you set to block-storage-broker, you should provide a suitable value for volume_size.; local
volume_size: (int) The volume size in GB to request from the block-storage-broker.; 5
volume_map: (string) YAML map as e.g. "{postgres/0: vol-0000010, postgres/1: vol-0000016}". A service unit to specific volume-id that should be attached to each unit. If the provider is set to block-storage-broker, volume-ids specified should 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. If the provider is set to partition, volume-ids should be a disk partition name (e.g. /dev/sdb1)
root: (string) The root path where external directories will be mounted.; /srv/data

Popular searches