Re: [openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?
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
Re: [openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?
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. > > > > ... > 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. > ... Thanks for answer! I should definitely try with those specific host/path/options. However, it seems that the (supposedly) deprecated way does not really work how it should, so I filed a bug report: https://bugs.launchpad.net/cinder/+bug/1694758 Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. __ 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
[openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?
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)? Jiri [1] https://docs.openstack.org/admin-guide/blockstorage-nfs-backend.html [2] https://docs.openstack.org/newton/config-reference/block-storage/drivers/nfs-volume-driver.html [3] https://github.com/openstack/cinder/commit/553e0d92c40c73aa1680743c4287f31770131c97 [4] https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L163 [5] https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/volume/nfs.py#L87 [6] https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/volume/nfs.py#L89 -- 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
[openstack-dev] [nova] Find out the instance availability zone before creating volume.
Hi all, it's a long time since I have opened proposal to fix bug https://bugs.launchpad.net/nova/+bug/1497253 "different availability zone for nova and cinder when AZ is not explicitly given". I know the solution is controversial, but could anyone interested give a look? To summarize what's the situation and proposed solution about: 1. User has cinder AZ's and nova AZ of the same names 2. AZ's physical location is different, and user wants instances to have same AZ as their volumes 3. This is generally achieved by setting cross_az_attach option to False, because since https://review.openstack.org/#/c/157041/ volumes are created in the same AZ as instances. 4. However, what if user doesn't explicitly provide AZ when creating the instance (so the scheduler can distribute the load evenly and according to available resources)? This is the situation possibly requiring a fix. In such case, nova uses the None value for availability zone at the time it calls volume_api.create. Cinder creates the volume in some AZ it has available, and when nova finishes creating the instance it creates it in some of its available AZ. There's no relation between these two, so if they end up being different, we'll hit the error " Instance %(instance)s and volume %(vol)s are not in the same availability_zone" So, my proposal (as expressed in https://review.openstack.org/225119) is that: - if cross_az_attach is set to false, nova should ensure cinder and nova AZ's are matching, AND it should make sure this rule is true also in the case when AZ was not specified by user. Thus I propose to look for instance's real AZ BEFORE actually trying to create the volume, and use this value also for volume. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republichttp://www.suse.cz __ 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
