V Wed, 31 May 2017 11:34:20 -0400
Eric Harney <ehar...@redhat.com> napsáno:

> On 05/25/2017 05:51 AM, Jiri Suchomel wrote:
> > Hi,
> > it seems to me that the way of adding extra NFS options to the
> > cinder backend is somewhat confusing.
> > 
> > 1. There is  nfs_mount_options in cinder config file [1]
> > 
> > 2. Then I can put my options to the nfs_shares_config file - that
> > it could contain additional options mentiones [2] or the
> > commit message that adds the feature [3]
> > 
> > Now, when I put my options to both of these places, cinder-volume
> > actually uses them twice and executes the command like this
> > 
> > mount -t nfs -o nfsvers=3 -o nfsvers=3
> > 192.168.241.10:/srv/nfs/vi7/cinder 
> > /var/lib/cinder/mnt/f5689da9ea41a66eff2ce0ef89b37bce
> > 
> > BTW, the options coming from nfs_shares_config are called 'flags' by
> > cinder/volume/drivers/nfs ([4]).
> > 
> > Now, to make it more fun, when I actually want to attach a volume to
> > running instance, nova uses different way of realizing which NFS
> > options to use:
> > 
> > - It reads them from _nova_ config option of
> > libvirt.nfs_mount_options [5]
> > - or it uses those it gets them from cinder when creating cinder
> > connection [6] But these are only the options defined in
> > nfs_shares_config file, NOT those nfs_mount_options specified in
> > cinder config file.
> > 
> > 
> > So. If I put my options to both places, nfs_shares_config file and
> > nfs_mount_options, it actually works how I want it to work, as
> > current mount does not complain that the option was provided twice. 
> > 
> > But it looks ugly. And I'm wondering - am I doing it wrong, or
> > is there a problem with either cinder or nova (or both)?
> >   
> 
> This has gotten a bit more confusing than in necessary in Cinder due
> to how the configuration for the NFS and related drivers has been
> tweaked over time.
> 
> The method of putting a list of shares in the nfs_shares_config file
> is effectively deprecated, but still works for now.
> 
> The preferred method now is to set the following options:
>    nas_host:  server address
>    nas_share_path:  export path
>    nas_mount_options:  options for mounting the export
> 
> So whereas before the nfs_shares_config file would have:
>    127.0.0.1:/srv/nfs1 -o nfsvers=3
> 
> This would now translate to:
>    nas_host=127.0.0.1
>    nas_share_path=/srv/nfs1
>    nas_mount_options = -o nfsvers=3
> 
> I believe if you try configuring the driver this way, you will get the
> desired result.

Nope, this does not work.
If I provide nas_mount_options, mount command tries to use them twice.

os_brick.remotefs.remotefs, _do_mount gets them in the form of "flags"
as well as "options" [1]:

- mount_flags are coming from the shares structure before
  cinder.volume.nfs calls _remotefsclient.mount [2]. They were written 
  there by cinder/volume/drivers/remotefs when the suggested nas_*
  configuration options were found[3]

- mount_options are created in the constructor of RemoteFsClient from
nfs_mount_options [4] which are passed from cinder.volume.drivers.nfs
[5][6] 

So this means that the mount command gets the options twice. 
But not only that! os-brick/remotefs.py's _do_mount adds an extra -o
option to the list of options (apparently because both
nas_mount_options and nfs_mount_options have different syntax!) which
makes the mount command fail for sure.


So, to summarize:

- nfs_mount_options in cinder conf is ignored when cinder connection
  is passed to nova
- nas_mount_options seems to be broken with NFS backend (as described
  above)
- options provided in nfs_shares_config file are passed to mount
  command twice, but this does not necessary hurt, so this solution
  actually works (and has additional bonus of possibility to define
  mount options per mount point)

Jiri

- 

[1]
https://github.com/openstack/os-brick/blob/stable/newton/os_brick/remotefs/remotefs.py#L114
[2]
https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L163
[3]
https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/remotefs.py#L463
[4] 
https://github.com/openstack/os-brick/blob/stable/newton/os_brick/remotefs/remotefs.py#L60
[5]
https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L99
[6]
https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L103






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


-- 
Jiri Suchomel

SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
18600 Praha 8

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to