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 <[email protected]>
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
