Volume Management - NFS Charm

[David Britton]

Hi --

I've been looking to build a persistence story into the NFS charm, and I'm
wondering if anyone else has thought of this problem before.  I opted to
use NFS since it exposes the "mount" interface, which allows a pretty easy
use case from relating charms.  I would expect that other file storage
charms would use something like this even if the ideas are not quite
fleshed out or uniform between charms yet.

My ideas are as follows.


1) Expose config settings for cloud volumes in the nfs charm.

cloud_credentials: base64 encoded shell script to source containing cloud
credentials
cloud_storage: pseudo-URL syntax for cloud storage device.  E.g.,
swift://block-storage-id

The hook would be smart enough to install the right package, and try to
attach and mount the volume after sourcing the credentials file.

The disadvantages are the hook is provider-specific, and would need to be
expanded for other clouds to be generally useful.


2) A storage subordinate charm.

E.g., swift-storage

You would add this subordinate to the NFS service, and it would have the
smarts to mount the block device at an agreed-upon location.

The disadvantages involve waiting on the subordinate before the NFS charm
is generally useful.  I'm not sure how the mechanics of this would work.


I really don't like either of the things I'm proposing, and was wondering
what others thought about these ideas.  Have you had any brainstorms about
it?  Have you come up with something better to try out?

Please let me know.  This seems to be a big missing puzzle piece in
practical juju usage right now, and I would love to hear others thoughts
(since I may be missing something).

Thanks!


-- 
David Britton <david.britton at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131117/6e74064c/attachment.html>