confusing usage of NFS config options

Bug #1694758 reported by Jiri Suchomel
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Cinder
New
Undecided
Unassigned

Bug Description

1. Documentation is bit confusing when mentioning where to put options to NFS shares:

- https://docs.openstack.org/admin-guide/blockstorage-nfs-backend.html mentiones nfs_mount_options

- https://docs.openstack.org/newton/config-reference/block-storage/drivers/nfs-volume-driver.html (see the Note) mentiones they could also be written in nfs_shares_config file.

2. Cinder code is actually using both of these locations

nfs_mount_options:

https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L92

options specified in nfs_shares_config file:

https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L162

When an options is specified on both places, mount command uses all of them:

https://github.com/openstack/os-brick/blob/stable/newton/os_brick/remotefs/remotefs.py#L118

(the ones from nfs_shares_config are passed as flags)

3. When attaching volume to the nova instance, nova (additionally to it's ability to use options specified in nova config file) should use the options passed from cinder connection:

https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/volume/nfs.py#L89

However, in this case only the options that were specified in nfs_shares_config file are passed, and not the one in nfs_mount_options

Revision history for this message
Jiri Suchomel (jsuchome) wrote :

Regarding point 3 (attaching volume to the instance), the configuration passed from cinder connection only includes the options written in nfs_shares_config file. See

https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/remotefs.py#L172

There seems to be a code that tries to use nas_mount_options:

https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/remotefs.py#L155

but this is not executed during the volume attach action.

So, we might need to pass the options explicitely in initialize_connection, something like:

diff --git a/cinder/volume/drivers/remotefs.py b/cinder/volume/drivers/remotefs.py
index 99481bd34..d69540175 100644
--- a/cinder/volume/drivers/remotefs.py
+++ b/cinder/volume/drivers/remotefs.py
@@ -172,8 +172,19 @@ class RemoteFSDriver(driver.BaseVD):
         """
         data = {'export': volume.provider_location,
                 'name': volume.name}
+
+ mount_options = []
         if volume.provider_location in self.shares:
- data['options'] = self.shares[volume.provider_location]
+ mount_options = self.shares[volume.provider_location].split(' ')
+
+ # FIXME: This should check both nfs and nas_mount options...
+ if self.configuration.nfs_mount_options:
+ mount_options = list(set(
+ mount_options + self.configuration.nfs_mount_options..split(' '))
+ )
+
+ if mount_options:
+ data['options'] = "-o " + mount_options
         return {
             'driver_volume_type': self.driver_volume_type,
             'data': data,

Although it still looks bit ugly and I'm not sure what should be the relation between nas_mount_options and nfs_mount_option if they both exist

Revision history for this message
Jiri Suchomel (jsuchome) wrote :

(sorry, the indentation was lost in my example, but I think the point is clear)

Revision history for this message
Jiri Suchomel (jsuchome) wrote :

So, my proposal from comment #1 is probably not correct.

It makes sense if the options are located in self.shares, so proper initialization would need to be done to read them. But it must be make sure that they are not mixed with other options potentially provided (nfs_mount_options vs nas_mount_options vs options in nfs_shares_config).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.