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-hj4Qjbh5Zgm...)
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.