Per the server SIG meeting last week, I've updated the requirements doc for the NFS role (https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...) to clean up the user stories, and the actual requirements.
I think that there's only one outstanding issue with this, and it relates to the UI for creating the underlying storage.
On 12/03/2016 11:01 PM, Jon Stanley wrote:
Per the server SIG meeting last week, I've updated the requirements doc for the NFS role (https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...) to clean up the user stories, and the actual requirements.
I think that there's only one outstanding issue with this, and it relates to the UI for creating the underlying storage.
I think it would be best to have this discussion with Andreas Nilsson (CCed), who is the Cockpit UX designer.
Andreas, the basic question is this: When exporting a new shared directory via NFS, should this UI also support/allow the creation of *new* volumes on the host machine? We currently have volume creation available in the storage functionality backed by storaged, of course.
Do we need to provide a second, parallel implementation for the NFS sharing UI? There are pros and cons, of course.
Pros: * In cases where the user is creating a new volume expressly for sharing, it might be a complicated workflow to go 1) to the storage tab and create a volume and then 2) go to the sharing tab separately and share the volume.
Cons: * It means having two possible ways to do the same task, which may be confusing for the user too.[1] * It means another path for QA to test.
If we decided to do this, we could opt to take a limited approach such as providing an option to create a new directory if free space was available in one or more logical volumes on the system, mounted to a well-known location on the disk. If free space isn't available, maybe offer to forward the user to the storage tab to do more advanced, custom configuration?
[1] Since they're using the same underlying implementation, either view should reflect any changes made by the other, so that is probably a mitigating factor.
On 2016-12-05 14:12, Stephen Gallagher wrote:
On 12/03/2016 11:01 PM, Jon Stanley wrote:
Per the server SIG meeting last week, I've updated the requirements doc for the NFS role (https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...) to clean up the user stories, and the actual requirements.
I think that there's only one outstanding issue with this, and it relates to the UI for creating the underlying storage.
I think it would be best to have this discussion with Andreas Nilsson (CCed), who is the Cockpit UX designer.
Andreas, the basic question is this: When exporting a new shared directory via NFS, should this UI also support/allow the creation of *new* volumes on the host machine? We currently have volume creation available in the storage functionality backed by storaged, of course.
Do we need to provide a second, parallel implementation for the NFS sharing UI? There are pros and cons, of course.
I agree with both the pros and cons, and my answer right now is "I don't know yet". How do you envision things to work in the CLI workflow?
I'm currently in the research phase of the Cockpit side of the design. Right now I'm collecting previous art and experimenting with NFS on my own systems to get a feel for it. https://github.com/cockpit-project/cockpit/wiki/Feature:-NFS-Server Feel free to add any other examples of other projects who does file sharing. - Andreas
On 12/05/2016 08:20 AM, Andreas Nilsson wrote:
On 2016-12-05 14:12, Stephen Gallagher wrote:
On 12/03/2016 11:01 PM, Jon Stanley wrote:
Per the server SIG meeting last week, I've updated the requirements doc for the NFS role (https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...)
to clean up the user stories, and the actual requirements.
I think that there's only one outstanding issue with this, and it relates to the UI for creating the underlying storage.
I think it would be best to have this discussion with Andreas Nilsson (CCed), who is the Cockpit UX designer.
Andreas, the basic question is this: When exporting a new shared directory via NFS, should this UI also support/allow the creation of *new* volumes on the host machine? We currently have volume creation available in the storage functionality backed by storaged, of course.
Do we need to provide a second, parallel implementation for the NFS sharing UI? There are pros and cons, of course.
I agree with both the pros and cons, and my answer right now is "I don't know yet". How do you envision things to work in the CLI workflow?
I'm actually not sure we're going to have a "workflow" at the command-line. Since we're planning to back as much of this as possible with Ansible, I would expect this to be a declarative interface rather than an interactive one. In which case, we would need to handle the storage creation and sharing as two independent steps.
(It's important to note that, due to technology limitations, "under the hood" this will always need to happen in two steps, because storage always has to exist and be mounted before the NFS daemon can start offering it).
I'm currently in the research phase of the Cockpit side of the design. Right now I'm collecting previous art and experimenting with NFS on my own systems to get a feel for it. https://github.com/cockpit-project/cockpit/wiki/Feature:-NFS-Server Feel free to add any other examples of other projects who does file sharing.
I added a link to the Synology Disk Station interface.
On Sat, Dec 03, 2016 at 11:01:06PM -0500, Jon Stanley wrote:
Per the server SIG meeting last week, I've updated the requirements doc for the NFS role (https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...) to clean up the user stories, and the actual requirements.
I think that there's only one outstanding issue with this, and it relates to the UI for creating the underlying storage.
Are you planning to support krb5 exports?
Under Requirements: 1, what about netgroups or dns wildcards?
Note that nfsd supports exporting subdirectories of filesystems as well as entire filesystem, but that support is inherently problematic. So, anything we can do to discourage that is welcome.
Under "Things that we need to do: 1) c) i)", unmounting an unexported filesystem is trickier than you'd expect: even after unexport, there are still some bits of state that can hang around holding references, so the only completely reliable way to do this is by stopping the server first (and then restarting it after unount).
When unexporting, it might be nice to warn that clients need to have unmounted first. (For extra credit, a list of possibly active clients could also be useful, but we have only very incomplete information about that right now, so that's best left as future work.)
Nit: s/machine has it's/machine has its/.
On containers: container support for knfsd is incomplete, so you won't be able to run different knfsd's inside containers. (That could change some day.)
--b.
server@lists.fedoraproject.org
-
Andreas Nilsson -
J. Bruce Fields -
Jon Stanley -
Stephen Gallagher