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?