storage ng ^#2

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?