Hi Niels, ----- Original Message ----- > From: "Niels de Vos" <ndevos@xxxxxxxxxx> > To: "Csaba Henk" <chenk@xxxxxxxxxx> > Cc: gluster-devel@xxxxxxxxxxx > Sent: Wednesday, January 28, 2015 9:19:34 AM > Subject: Re: Ability to turn off 'glusterfs' protocol > > The High-Availability NFS-Ganesha design puts the NFS-Ganesha service in > the trusted storage pool, possibly on the servers hosting bricks. Maybe > you can comment on why this is not suitable or wished for in your > environment? This design basically swaps Gluster/NFS for NFS-Ganesha. > > http://www.gluster.org/community/documentation/index.php/Features/HA_for_ganesha > [...] > > I'm not sure if you're talking about this? > > http://www.gluster.org/community/documentation/index.php/Features/Gluster_CLI_for_ganesha > > At the moment, I think that also assumes the NFS-Ganesha service is > running inside the trusted storage pool. If you need any of those > functions available outside of the trusted storage pool, get in touch > with the feature owners and keep the gluster-devel list on CC. The resources you mention elaborate on an effort to integrate Ganesha into the Gluster cluster. Which is very nice, but it's simply not what we want. In the cloud context we take the management of the Ganesha service(s) completely upon us. There, for example, it might be the case that the tenant will be network separated from the Gluster cluster, and the node where Ganesha resides will be set up to be connected to both netwokrs (of tenant and of the Gluster cluster), and thus, implied by said separation, it won't be included in either. Anyway, we can forget Ganesha. TL;DR: what we need that from a given cloud that uses the Gluster cluster as an external backend we want a general ban on glusterfs proto access, but make it possible to specify some exceptions. Regards Csaba _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
