storage #5

Supports: trusty

Add to new model

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.

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

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
root
(string) The root path where external directories will be mounted.
/srv/data
store_encryption_keys
(string) If the volume is encrypted, this will write the details to disk to allow auto-mounting.
yes
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)
volume_size
(int) The volume size in GB to request from the block-storage-broker.
5