I'd like some feedback on a (very early) draft that I have of the document for the NFS role definition (if you'd like edit access, just shoot me an email):
https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...
How I thought of this was to go from user stories, to technical requirements, and finally to activities to meet those requirements. The actor in all of the user stories in an inexperienced admin - are there other actors that we need to be concerned with?
Totally open to feedback here - is this even on the right path?
On 10/26/2016 08:44 AM, Jon Stanley wrote:
I'd like some feedback on a (very early) draft that I have of the document for the NFS role definition (if you'd like edit access, just shoot me an email):
https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...
How I thought of this was to go from user stories, to technical requirements, and finally to activities to meet those requirements. The actor in all of the user stories in an inexperienced admin - are there other actors that we need to be concerned with?
Totally open to feedback here - is this even on the right path?
I think this approach makes perfect sense.
The other actor I think we should be concerned with is the *experienced* administrator. We aren't building this specifically for them, but we should have stipulations that we don't get in their way, I think.
I'll make a few suggestions on the doc.
On Fri, Oct 28, 2016 at 8:45 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I'll make a few suggestions on the doc.
As for one of the suggestions that was made on the doc, I'd rather have this discussion on the list than in the doc.
I'm pretty firmly against this. We already have UI in Cockpit for creating new volumes using storaged. If we do anything specific here, we should just redirect people to that spoke in Cockpit.
(note to readers: "this" is referring to creation of the underlying storage as part of the NFS server role)
Are we going to provide something useful, or a construction kit to make useful things? I think that we're targeting inexperienced admins, therefore I think that a frictionless experience from out of the box to something that is up providing services on the network is the standard that we should strive for.
That being said, I'm also not saying that we need to reinvent the wheel - using the existing functionality obviously makes a lot of sense, but I think that the integration and experience of the user has to be paramount here. That's really all that I was trying to capture there.
Hi. The NFS server GUI seems to (partly) a re-iteration of an idea that has been propsed some time ago already: https://lists.fedoraproject.org/pipermail/fedora-server-list/2015-May/001876...
On Fri, 28 Oct 2016 15:42:18 -0400 Jon Stanley jonstanley@gmail.com wrote:
On Fri, Oct 28, 2016 at 8:45 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I'll make a few suggestions on the doc.
As for one of the suggestions that was made on the doc, I'd rather have this discussion on the list than in the doc.
I'm pretty firmly against this. We already have UI in Cockpit for creating new volumes using storaged. If we do anything specific here, we should just redirect people to that spoke in Cockpit.
(note to readers: "this" is referring to creation of the underlying storage as part of the NFS server role)
Are we going to provide something useful, or a construction kit to make useful things? I think that we're targeting inexperienced admins, therefore I think that a frictionless experience from out of the box to something that is up providing services on the network is the standard that we should strive for.
There are existing products with existing user-base having similar functionality (FreeNAS, Open Media Vault,...). Wouldn't it make sense to get inspired there?
Regards,
On 10/31/2016 03:42 AM, Tomáš Smetana wrote:
Hi. The NFS server GUI seems to (partly) a re-iteration of an idea that has been propsed some time ago already: https://lists.fedoraproject.org/pipermail/fedora-server-list/2015-May/001876...
I don't think we want to deliver this as a completely separate install. There are plenty of NAS-focused distributions out there and I don't think there's much value in trying to play in that space.
I *do* think there's value in being a general-purpose server that has very good (and approachable) NAS functionality.
On Fri, 28 Oct 2016 15:42:18 -0400 Jon Stanley jonstanley@gmail.com wrote:
On Fri, Oct 28, 2016 at 8:45 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I'll make a few suggestions on the doc.
As for one of the suggestions that was made on the doc, I'd rather have this discussion on the list than in the doc.
I'm pretty firmly against this. We already have UI in Cockpit for creating new volumes using storaged. If we do anything specific here, we should just redirect people to that spoke in Cockpit.
(note to readers: "this" is referring to creation of the underlying storage as part of the NFS server role)
Are we going to provide something useful, or a construction kit to make useful things? I think that we're targeting inexperienced admins, therefore I think that a frictionless experience from out of the box to something that is up providing services on the network is the standard that we should strive for.
There are existing products with existing user-base having similar functionality (FreeNAS, Open Media Vault,...). Wouldn't it make sense to get inspired there?
Yes, in terms of providing UI, we should absolutely look at existing NAS-specific services.
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
On Tue, Nov 1, 2016 at 7:55 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
I honestly think that would obviate the need for any of this (other than the Cockpit UI to actually configure it), and would make for a more integrated user experience. Unfortunately, I'm not a C developer and could probably not provide direct code contributions to teach it NFS (would be more than willing to test/provide input/etc)
On 11/01/2016 08:15 AM, Jon Stanley wrote:
On Tue, Nov 1, 2016 at 7:55 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
I honestly think that would obviate the need for any of this (other than the Cockpit UI to actually configure it), and would make for a more integrated user experience. Unfortunately, I'm not a C developer and could probably not provide direct code contributions to teach it NFS (would be more than willing to test/provide input/etc)
For the record, the Cockpit interaction is in JavaScript and the storaged API is D-BUS (a language-agnostic protocol). So if there's anyone out there with some JavaScript skills who would like to implement this, give a holler!
On Tue, Nov 01, 2016 at 08:25:26AM -0400, Stephen Gallagher wrote:
On 11/01/2016 08:15 AM, Jon Stanley wrote:
On Tue, Nov 1, 2016 at 7:55 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
I honestly think that would obviate the need for any of this (other than the Cockpit UI to actually configure it), and would make for a more integrated user experience. Unfortunately, I'm not a C developer and could probably not provide direct code contributions to teach it NFS (would be more than willing to test/provide input/etc)
For the record, the Cockpit interaction is in JavaScript and the storaged API is D-BUS (a language-agnostic protocol). So if there's anyone out there with some JavaScript skills who would like to implement this, give a holler!
For what it's worth, I believe the Ganesha folks designed a D-BUS interface to their userland NFS server. It might be worth looking at as a starting point to configure knfsd as well? Frank, is this the right reference?:
https://github.com/nfs-ganesha/nfs-ganesha/wiki/Dbusinterface
I'm not very familiar with it so don't necessarily endorse the idea, but maybe it's worth looking into.
The tricky part about managing nfsd tends not be nfsd itself so much as the other stuff (rpcbind, statd, mountd) that it depends on. For that we just want to use systemd and benefit from all the debugging that's gone into those unit files.
--b.
On Tue, Nov 01, 2016 at 12:00:01PM -0400, J. Bruce Fields wrote:
On Tue, Nov 01, 2016 at 08:25:26AM -0400, Stephen Gallagher wrote:
On 11/01/2016 08:15 AM, Jon Stanley wrote:
On Tue, Nov 1, 2016 at 7:55 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
I honestly think that would obviate the need for any of this (other than the Cockpit UI to actually configure it), and would make for a more integrated user experience. Unfortunately, I'm not a C developer and could probably not provide direct code contributions to teach it NFS (would be more than willing to test/provide input/etc)
For the record, the Cockpit interaction is in JavaScript and the storaged API is D-BUS (a language-agnostic protocol). So if there's anyone out there with some JavaScript skills who would like to implement this, give a holler!
For what it's worth, I believe the Ganesha folks designed a D-BUS interface to their userland NFS server. It might be worth looking at as a starting point to configure knfsd as well? Frank, is this the right reference?:
https://github.com/nfs-ganesha/nfs-ganesha/wiki/Dbusinterface
I'm not very familiar with it so don't necessarily endorse the idea, but maybe it's worth looking into.
Speaking of which, why bother with knfsd? I suggest we can provide Ganesha-NFS as a core of NFS role. It has a DBUS API and it seem to be used in entepris filers.
On Tue, Nov 01, 2016 at 05:49:14PM +0100, Tomasz Torcz wrote:
On Tue, Nov 01, 2016 at 12:00:01PM -0400, J. Bruce Fields wrote:
On Tue, Nov 01, 2016 at 08:25:26AM -0400, Stephen Gallagher wrote:
On 11/01/2016 08:15 AM, Jon Stanley wrote:
On Tue, Nov 1, 2016 at 7:55 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
I honestly think that would obviate the need for any of this (other than the Cockpit UI to actually configure it), and would make for a more integrated user experience. Unfortunately, I'm not a C developer and could probably not provide direct code contributions to teach it NFS (would be more than willing to test/provide input/etc)
For the record, the Cockpit interaction is in JavaScript and the storaged API is D-BUS (a language-agnostic protocol). So if there's anyone out there with some JavaScript skills who would like to implement this, give a holler!
For what it's worth, I believe the Ganesha folks designed a D-BUS interface to their userland NFS server. It might be worth looking at as a starting point to configure knfsd as well? Frank, is this the right reference?:
https://github.com/nfs-ganesha/nfs-ganesha/wiki/Dbusinterface
I'm not very familiar with it so don't necessarily endorse the idea, but maybe it's worth looking into.
Speaking of which, why bother with knfsd? I suggest we can provide Ganesha-NFS as a core of NFS role. It has a DBUS API and it seem to be used in entepris filers.
Re-adding Frank to the cc so he can keep me honest. (He maintains Ganesha, I maintain knfsd).
There's currently a lot of work being done on Ganesha to export large scale-out filesystems (Gluster, Ceph). But knfsd will usually work better for local filesystems. In some more detail:
Ganesha advantages: - Ganesha is in userspace, making development easier in some ways. - Ganesha is easier to integrate with filesystems that live primarily in userspace (like Ganesha and Ceph); otherwise they'd have to go through FUSE. - probably some more features I don't know about since I pay less attention to Ganesha (better statistics-gathering? D-BUS interface?) knfsd pros: - knfsd is more mature and more widely used. - knfsd has more complete protocol support (e.g., I believe NFSv4.1 and 4.2 implementation are further along). - knfsd has better integration with the kernel vfs. We've done some work here to make things easier for Ganesha (e.g. on system calls to support filehandle lookup from userspace), but there's more to do.
I suspect that the first target for this initiative is single-server exports of local filesystems, in which case we'll want to start with knfsd.
--b.
On Tue, Nov 1, 2016 at 1:21 PM, J. Bruce Fields bfields@redhat.com wrote:
I suspect that the first target for this initiative is single-server exports of local filesystems, in which case we'll want to start with knfsd.
Yes, I assume that any sort of pNFS implementation is permanently out of scope for this.
On Tue, Nov 1, 2016 at 7:55 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I also spoke with David Lehman on IRC yesterday who noted that storaged is looking at adding API for dealing with NFS shares. He indicated that if there's a strong desire for that, we should let them know so they can prioritize it.
Has there been any forward motion on this? Is David on this list? I'd be interested in hearing his thoughts on how he might think it would work.
On Oct 26, 2016 07:44, "Jon Stanley" jonstanley@gmail.com wrote:
I'd like some feedback on a (very early) draft that I have of the document for the NFS role definition (if you'd like edit access, just shoot me an email):
https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...
How I thought of this was to go from user stories, to technical requirements, and finally to activities to meet those requirements. The actor in all of the user stories in an inexperienced admin - are there other actors that we need to be concerned with?
Totally open to feedback here - is this even on the right path? _______________________________________________
Could this also include an NFS client role? It would be great if the one cockpit instance would let me create an export on server A, and present that export in the cockpit UI as an available mount for server B.
Aside, I'd love an NFS+gluster role for similar use cases.
--Pete
On Tue, Nov 1, 2016 at 1:12 PM, Pete Travis lists@petetravis.com wrote:
Could this also include an NFS client role? It would be great if the one cockpit instance would let me create an export on server A, and present that export in the cockpit UI as an available mount for server B.
Yes, I had planned on that in my head, but not explicitly written it down. Sorry about that!
On 11/01/2016 01:12 PM, Pete Travis wrote:
On Oct 26, 2016 07:44, "Jon Stanley" <jonstanley@gmail.com mailto:jonstanley@gmail.com> wrote:
I'd like some feedback on a (very early) draft that I have of the document for the NFS role definition (if you'd like edit access, just shoot me an email):
https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a-...
How I thought of this was to go from user stories, to technical requirements, and finally to activities to meet those requirements. The actor in all of the user stories in an inexperienced admin - are there other actors that we need to be concerned with?
Totally open to feedback here - is this even on the right path? _______________________________________________
Could this also include an NFS client role? It would be great if the one cockpit instance would let me create an export on server A, and present that export in the cockpit UI as an available mount for server B.
I'm not sure that we specifically need a client *role* for this. It kind of depends on what we decide belongs in the base offering of Fedora Server.
In my view, storage is kind of a bootstrapping thing. I'm not sure I'd want to install a special module just to attach to my storage servers; I'd expect to be able to do that out-of-the-box.
I spoke with the Cockpit developers; they've got plans and a design for adding NFS client support to Cockpit proper. They haven't prioritized it yet, but we can ask.
Aside, I'd love an NFS+gluster role for similar use cases.
Once you start getting into clustered deployments, I'm not sure the model we're using *quite* fits in. That sort of thing really needs orchestration at a higher level than per-machine.
On Tue, Nov 1, 2016 at 1:10 PM, Stephen Gallagher sgallagh@redhat.com wrote:
I'm not sure that we specifically need a client *role* for this. It kind of depends on what we decide belongs in the base offering of Fedora Server.
In my view, storage is kind of a bootstrapping thing. I'm not sure I'd want to install a special module just to attach to my storage servers; I'd expect to be able to do that out-of-the-box.
I spoke with the Cockpit developers; they've got plans and a design for adding NFS client support to Cockpit proper. They haven't prioritized it yet, but we can ask.
I would agree here. Since we are focused on the Server implementation, the client role doesn't need to be formalized from our WG. Certainly we need to test the functionality of the implemented Server role though. Perhaps we should work closely with the Workstation WG who would likely own the client roles?
On 11/01/2016 04:23 PM, Vinny Valdez wrote:
On Tue, Nov 1, 2016 at 1:10 PM, Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com> wrote:
I'm not sure that we specifically need a client *role* for this. It kind of depends on what we decide belongs in the base offering of Fedora Server. In my view, storage is kind of a bootstrapping thing. I'm not sure I'd want to install a special module just to attach to my storage servers; I'd expect to be able to do that out-of-the-box. I spoke with the Cockpit developers; they've got plans and a design for adding NFS client support to Cockpit proper. They haven't prioritized it yet, but we can ask.
I would agree here. Since we are focused on the Server implementation, the client role doesn't need to be formalized from our WG. Certainly we need to test the functionality of the implemented Server role though. Perhaps we should work closely with the Workstation WG who would likely own the client roles?
That's not what I was saying, actually. Being able to connect to storage is definitely a server function. I just disagree that it should happen at the level of a Server Role. I think it's core functionality.
I would have to agree and disagree as both of you have merit in your debate. Core roles of servers having access to data storage really depends. In most cases I see it often as a server admin function to handle, and in other cases I've seen entirely independent departments whom handle it. I honestly feel it would be best to have it added into the Fedora Server itself so it's their and give the end client the ability to choose if they want to use it or not. Thank you for your time.
Sincerely,
Garrett B. Leonard 360-990-3049
From: Stephen Gallagher sgallagh@redhat.com To: server@lists.fedoraproject.org Sent: Tuesday, November 1, 2016 1:26 PM Subject: Re: NFS Role Definition
On 11/01/2016 04:23 PM, Vinny Valdez wrote:
On Tue, Nov 1, 2016 at 1:10 PM, Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com> wrote:
I'm not sure that we specifically need a client *role* for this. It kind of depends on what we decide belongs in the base offering of Fedora Server.
In my view, storage is kind of a bootstrapping thing. I'm not sure I'd want to install a special module just to attach to my storage servers; I'd expect to be able to do that out-of-the-box.
I spoke with the Cockpit developers; they've got plans and a design for adding NFS client support to Cockpit proper. They haven't prioritized it yet, but we can ask.
I would agree here. Since we are focused on the Server implementation, the client role doesn't need to be formalized from our WG. Certainly we need to test the functionality of the implemented Server role though. Perhaps we should work closely with the Workstation WG who would likely own the client roles?
That's not what I was saying, actually. Being able to connect to storage is definitely a server function. I just disagree that it should happen at the level of a Server Role. I think it's core functionality.
_______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org
On 11/01/2016 08:19 PM, Garrett Leonard wrote:
I would have to agree and disagree as both of you have merit in your debate. Core roles of servers having access to data storage really depends. In most cases I see it often as a server admin function to handle, and in other cases I've seen entirely independent departments whom handle it.
I honestly feel it would be best to have it added into the Fedora Server itself so it's their and give the end client the ability to choose if they want to use it or not.
Thank you for your time.
Everyone agrees that Fedora Server needs to have the ability to connect to NFS servers. The only thing being debated really is whether the functionality is included in the default installation of Fedora Server or is rolled into an NFS Client module that you can choose to add in after the fact.
Personally, in my own opinion, I feel it would be best to just have it built into the server itself, and just let the end user determine if they want to use that feature or not. As there are circumstances they wont have the ability to get any add ons once installed etc. depending what's going on. The more features available immediately opening the box, the more streamlined end users can plan migrations and the major things with all the little things already in place. Thank you for your time.
Sincerely,
Garrett B. Leonard 360-990-3049
From: Stephen Gallagher sgallagh@redhat.com To: server@lists.fedoraproject.org Sent: Tuesday, November 1, 2016 5:32 PM Subject: Re: NFS Role Definition
On 11/01/2016 08:19 PM, Garrett Leonard wrote:
I would have to agree and disagree as both of you have merit in your debate. Core roles of servers having access to data storage really depends. In most cases I see it often as a server admin function to handle, and in other cases I've seen entirely independent departments whom handle it.
I honestly feel it would be best to have it added into the Fedora Server itself so it's their and give the end client the ability to choose if they want to use it or not. Thank you for your time.
Everyone agrees that Fedora Server needs to have the ability to connect to NFS servers. The only thing being debated really is whether the functionality is included in the default installation of Fedora Server or is rolled into an NFS Client module that you can choose to add in after the fact.
_______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org
server@lists.fedoraproject.org