After today's Server SIG meeting, I put together a straw-man[1] for what an Ansible API for configuring NFS shares might look like. (Apologies for not including it inline, but the Markdown formatting is really ugly, so please just look at it on the web).
Feedback on this is highly desirable, but please keep server@lists.fp.o in the CC when you do so.
[1] https://github.com/libre-server/proposals/blob/master/NFS/NFS_ansible.md
On Tue, Mar 28, 2017 at 09:15:33PM -0400, Stephen Gallagher wrote:
After today's Server SIG meeting, I put together a straw-man[1] for what an Ansible API for configuring NFS shares might look like. (Apologies for not including it inline, but the Markdown formatting is really ugly, so please just look at it on the web).
Feedback on this is highly desirable, but please keep server@lists.fp.o in the CC when you do so.
[1] https://github.com/libre-server/proposals/blob/master/NFS/NFS_ansible.md
I know NFS but not Ansible. Do you also need a way to start and stop the server?
I think the thread count is another commonly needed parameter--the default of 8 threads is a little small.
"remote_path is in there as a future-compatible option; in the container world, we may have the ability to "fake" the mount point to the client, so I added that as an option here. I'm not sure whether to keep it or drop it." I'm not sure containers would do that for you. Once upon a time I had rpc.mountd patches to implement this, but wasn't sure if it was an interesting feature to anyone.
--b.
On 03/28/2017 08:54 PM, J. Bruce Fields wrote:
I know NFS but not Ansible. Do you also need a way to start and stop the server?
This step should be done using the existing 'service' or 'systemd' Ansible module.
http://docs.ansible.com/ansible/service_module.html http://docs.ansible.com/ansible/systemd_module.html
Those modules are very generic and could be used to start/stop the NFS server.
-- Major Hayden
On 03/28/2017 09:54 PM, J. Bruce Fields wrote:
On Tue, Mar 28, 2017 at 09:15:33PM -0400, Stephen Gallagher wrote:
After today's Server SIG meeting, I put together a straw-man[1] for what an Ansible API for configuring NFS shares might look like. (Apologies for not including it inline, but the Markdown formatting is really ugly, so please just look at it on the web).
Feedback on this is highly desirable, but please keep server@lists.fp.o in the CC when you do so.
[1] https://github.com/libre-server/proposals/blob/master/NFS/NFS_ansible.md
I know NFS but not Ansible. Do you also need a way to start and stop the server?
As Major says, I think this is probably handled by the existing "service" module, though there's an argument to be made about whether we might need to make some modifications to handle this transparently on OSes still using sysv/upstart rather than systemd.
I think the thread count is another commonly needed parameter--the default of 8 threads is a little small.
So, this is a feature like the ID-mapping and stuff that I'm beginning to think probably should be a separate Ansible module specifically for configuring global settings of the NFS server. So perhaps we should rename the module described in this proposal to "nfs_share" rather than just "nfs" and use the name "nfs" for that purpose.
"remote_path is in there as a future-compatible option; in the container world, we may have the ability to "fake" the mount point to the client, so I added that as an option here. I'm not sure whether to keep it or drop it." I'm not sure containers would do that for you. Once upon a time I had rpc.mountd patches to implement this, but wasn't sure if it was an interesting feature to anyone.
Well, if nothing else we could always have the module just do a bind mount of the local_path location into the remote_path location so that it could be referenced by the latter name; I don't think it would require any changes to the existing NFS server.
On Wed, Mar 29, 2017 at 09:06:50AM -0400, Stephen Gallagher wrote:
On 03/28/2017 09:54 PM, J. Bruce Fields wrote:
I think the thread count is another commonly needed parameter--the default of 8 threads is a little small.
So, this is a feature like the ID-mapping and stuff that I'm beginning to think probably should be a separate Ansible module specifically for configuring global settings of the NFS server. So perhaps we should rename the module described in this proposal to "nfs_share" rather than just "nfs" and use the name "nfs" for that purpose.
Note also that a lot of those settings will only take effect on server restart.
Also, you generally want to restart after an export removal. (The unexport will work, but often people are unexporting so they can unmount, and that's not reliable as knfsd can still hold some filesystem references after the unexport.)
Anyway, maybe none of that's Ansible's problem, but it's worth at least mentioning in documentation if there's a chance.
"remote_path is in there as a future-compatible option; in the container world, we may have the ability to "fake" the mount point to the client, so I added that as an option here. I'm not sure whether to keep it or drop it." I'm not sure containers would do that for you. Once upon a time I had rpc.mountd patches to implement this, but wasn't sure if it was an interesting feature to anyone.
Well, if nothing else we could always have the module just do a bind mount of the local_path location into the remote_path location so that it could be referenced by the latter name; I don't think it would require any changes to the existing NFS server.
Remembering now what I did a few years ago: I did bind mounts under /var/lib/nfsroot/ (or something like that) then added support for a new rpc.mountd option so e.g. like "nfsroot=/var/lib/nfsroot/" would make a path "/var/lib/nfsroot/export" mountable by a client as just "/export".
--b.
On 03/29/2017 11:52 AM, J. Bruce Fields wrote:
On Wed, Mar 29, 2017 at 09:06:50AM -0400, Stephen Gallagher wrote:
On 03/28/2017 09:54 PM, J. Bruce Fields wrote:
I think the thread count is another commonly needed parameter--the default of 8 threads is a little small.
So, this is a feature like the ID-mapping and stuff that I'm beginning to think probably should be a separate Ansible module specifically for configuring global settings of the NFS server. So perhaps we should rename the module described in this proposal to "nfs_share" rather than just "nfs" and use the name "nfs" for that purpose.
Note also that a lot of those settings will only take effect on server restart.
Also, you generally want to restart after an export removal. (The unexport will work, but often people are unexporting so they can unmount, and that's not reliable as knfsd can still hold some filesystem references after the unexport.)
Anyway, maybe none of that's Ansible's problem, but it's worth at least mentioning in documentation if there's a chance.
Well, if that's a real issue, we can probably have the `unshared` state do a restart instead of just a reload. Thanks for the feedback!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/29/2017 10:57 AM, Stephen Gallagher wrote:
Anyway, maybe none of that's Ansible's problem, but it's worth at least mentioning in documentation if there's a chance.
Well, if that's a real issue, we can probably have the `unshared` state do a restart instead of just a reload. Thanks for the feedback!
Have we considered bringing up some of this on ansible-devel? My gut says that others have probably worked on an effort like this before or may be working on it now.
When I've done NFS, I've used this (aging) role:
https://github.com/geerlingguy/ansible-role-nfs
It could use a few cleanups in places (I need to submit some PR's) and it might not need any tinkering for Fedora. If we really want to make a module for /etc/exports, we could still go that route.
- -- Major Hayden
server@lists.fedoraproject.org
-
J. Bruce Fields -
Major Hayden -
Stephen Gallagher