canonical / nfs-client-operator

A subordinate Juju operator for requesting and mounting exported NFS shares on virtual machines.

NFS client operator

A subordinate Juju operator for requesting and mounting exported NFS shares on virtual machines.

Features

The NFS client operator requests and mounts exported NFS shares on virtual machines. This operator embeds the nfs-common package which contains several support files common to both NFS clients and servers. Network File System (NFS) itself is a distributed file system protocol for sharing files between heterogeneous environments over a network.

Usage

NFS client operator is a subordinate operator; it must be integrated with a principle operator for it to deploy successfully. For more information on how Juju operators work and how manage them, please refer to the Juju documentation. This operator should be used with Juju 3.x or greater.

With NFS server proxy operator

$ juju deploy nfs-server-proxy --config endpoint=nfs://12.34.56.78/data
$ juju deploy nfs-client data --config mountpoint=/data
$ juju deploy ubuntu base --base [email protected]
$ juju integrate data:juju-info base:juju-info
$ juju integrate data:nfs-share nfs-server-proxy:nfs-server-proxy

With LXD containers

If you are deploying Juju operators to an LXD container-based cloud substrate, you must modify the default LXD profile. The LXD containers must be super-privileged and have their AppArmor profile modified to allow nfs and rpc_pipefs mounts to successfully mount NFS shares. You can use the following commands to modify the default LXD profile to allow NFS mounts:

$ lxc profile set default security.privileged true
$ lxc profile set default raw.apparmor 'mount fstype=nfs*, mount fstype=rpc_pipefs'

Project & Community

The NFS client operator is a project of the Ubuntu HPC community. It is an open source project that is welcome to community involvement, contributions, suggestions, fixes, and constructive feedback. Interested in being involved with the development of the NFS client operator? Check out these links below:

• Join our online chat
• Contributing guidelines
• Code of conduct
• File a bug report
• Juju SDK docs

License

The NFS client operator is free software, distributed under the Apache Software License, version 2.0. See the LICENSE file for more information.

nfs-client-operator's Issues

NFS mounts are not preserved between machine reboots

Bug Description

If a Juju machine is rebooted after the NFS client operator is fully provisioned (e.g. successfully mounts NFS share exported by NFS server proxy operator), the client will not remount the share, but will say that the share is mounted. This creates a bad experience as you either need to:

1. Go inside the charm and manually remount the NFS share.
2. Tear down the namespaced NFS client operator and redeploy with the old endpoint.

However, the user will not figure this out until after they realize their cluster is non-functioning. This needs to be fixed.

To Reproduce

1. Have existing Charmed HPC cluster.
2. Reboot either slurmd or slurmctld node that has successfully mounted an NFS share.
3. See problem.

Environment

• Juju 3.1/stable
• latest/edge release of NFS client operator
• latest/edge release of SLURM charms.
• OpenStack (Serverstack)

Relevant log output

N/A - Just sadness and misery that the NFS mount is non-existent after reboot.

Additional context

Autofs to the rescue. The embedded NFS mount manager will most likely need to be updated so that autofs is automatically populated when a new NFS share is intercepted. https://help.ubuntu.com/community/Autofs has more information.

Cannot mount NFS shares with IPv6 addresses

The NFS client operator currently fails to mount NFS shares on units if the NFS server is assigned an IPv6 address or the NFS server proxy is exporting an IPv6 NFS share address. The issue is with the mount -t nfs ... command that is being used to mount the shares. Since IPv6 addresses contain colons, if mounting using a shell command, the IPv6 address needs to be encapsulated by colons; the NFS operator currently does not do this. Therefore, if the operator attempts to mount an NFS share with an IPv6 address, it will fail.

This is relatively easy fix. We should consider using /etc/fstab or autofs in the fix because then we won't need to worry about remounting shares after a machine reboot. Adjacent to issue #5

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/check-cla.yaml

• canonical/has-signed-canonical-cla v1

.github/workflows/ci.yaml

• actions/checkout v4
• get-woke/woke-action v0
• actions/checkout v4
• actions/checkout v4
• canonical/charming-actions 2.4.0
• actions/checkout v4
• actions/checkout v4

.github/workflows/release.yaml

• actions/checkout v4
• canonical/charming-actions 2.4.0
• canonical/charming-actions 2.4.0

pip_requirements

requirements.txt

• ops == 2.*

---

• Check this box to trigger a request for Renovate to run again on this repository