juju deploy nfs-ganesha
Discuss this charm
Share your thoughts on this charm with the community on discourse.
This charm deploys NFS-Ganesha, a userspace NFS server.
At the moment, there is no clustering or federation (although this may be added in future). This is not a highly-available server.
To deploy an NFS-Ganesha server::
juju deploy nfs-ganesha
Each relation to the NFS-Ganesha charm will result in a new export for the
units in that application. The default location of data is
Note that the NFS-Ganesha charm will not destroy data. This means if you remove a relation to an application, you will need to manually destroy the data saved by that application in the local data location.
This charm currently only supports the VFS file system abstraction layer, and does not support HA or clustering. If you need the latter, you may be better off using the native CephFS NFS share support in OpenStack Pike or later.
conjure-up canonical-kubernetes juju deploy nfs-ganesha juju add-relation nfs-ganesha kubernetes-worker
juju deploy nfs-ganesha juju deploy mysql juju deploy owncloud juju add-relation mysql owncloud juju add-relation nfs-ganesha:nfs-ganesha owncloud:shared-fs
The above example deploys OwnCloud personal cloud storage, and provides remote storage via the NFS host.
juju deploy nfs-ganesha juju deploy mysql juju deploy wordpress juju add-relation mysql:db wordpress:db juju add-relation nfs-ganesha:nfs-ganesha wordpress:nfs
To migrate storage from one NFS-Ganesha unit to another, first add the new unit in such a way as to avoid publishing it before it's ready:
juju config nfs-ganesha active_units=<old unit ID> juju add-unit nfs-ganesha
Now start the downtime:
juju config nfs-ganesha active_units=none
Wait for all clients to unmount, then move the underlying storage to the new unit in whatever way is appropriate for your deployment.
Finish the downtime by publishing the new unit:
juju config nfs-ganesha active_units=<new unit ID>
After clients have mounted the new unit and you've checked that all is well, you can remove the old unit:
juju remove-unit <old unit ID> juju config nfs-ganesha active_units=
Note that the migration process is quite abrupt: the server does not wait for all clients on related units to unmount before stopping. Consider arranging separately for downtime of clients that might write to their NFS mounts.
Known Limitations and Issues
No high availability story
At present the charms consuming an NFS relationship only account for a single host. Most charms assume the first incoming NFS mount-point is the sole replacement, and subsequent NFS relationship-join requests are ignored.
- storage_root: The root path where exported directories will be created.
- squash: What kind of user ID squashing is performed (No_Root_Squash, Root_Id_Squash, Root_Squash, or All_Squash).
- mount_options: The default client mount options.
- active_units: If set, a comma-separated list of unit names that should publish data on the 'mount' relation.
Colin Watson firstname.lastname@example.org
Upstream NFS-Ganesha Project
- To view the source: https://git.launchpad.net/nfs-ganesha-charm