<div dir="ltr"><div><div><div><div>Hearing all the prev discussions, thinking more about this requirement there are a few different scenarios here and this is my take on them:<br><br></div>1) Scenario 1: ganesha server running inside glusterfs TSP (trusted storage pool) - we just need to use the option to turn off glusterfs protocol <br></div><br>2) Scenario 2: ganesha server running outside of glusterfs TSP (This is very much possible and needed for Manila, since it has the concept of serving shares over a service VM for providing network isolation): In this case we don't use option of turning off glusterfs protocol, instead just use auth.allow <service VM IP> to ensure only service VM can access the glusterfs pool. There is a small caveat here tho'... the service VM in openstack will be configured to access glusterfs server via the neutron router and br-ex external bridge and the way neutron sets it up is that it enables SNAT (source nat) which causes the source IP of the network packet to change by the time it reaches glusterfs server. So auth.allow <serviceVM IP> won't work. This issue is openstack specific but if this won't work, then Scenario 2 will be difficult to achieve in Manila, something to ponder upon by Manila folks.<br><br></div>3) Scenario 3: Manila using gluster volume's subdir as shares instead of whole volume. Here each subdir inside the glusterfs volume is 1 Manila share and it can be spread across different tenants in a real world public cloud usecase. Going by the Manila servcie VM design, it creates 1 service VM per tenant,so Manila driver need to keep track of each service VM and adds its IP to the auth.allow as and when new service VM keeps coming up which again points back to the issue depicted in #2 above.<br><br></div><div>4) Scenario 4 : We use gluster-nfs (for cases where older version of gluster is present or some other reason): We can use glusterfs protocol off feature to ensure the volume is not accessible to un-trusted client over glusterfs protocol.<br></div><div><br></div>So it looks like the ability to turn off glusterfs protocol completely is only useful for Scenario 1 & 4.<br>Scenarios 2 & 3 have bigger issues to deal with on Manila side given the way neutron sets up networking in openstack (unless we don't use auth.allow at all, which means the glusterfs volume is open for all)<br><br>thanx,<br>deepak<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 1:49 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 27, 2015 at 08:29:49PM +0000, Csaba Henk wrote:<br>
> On Tue, 27 Jan 2015 11:39:52, Niels de Vos <ndevos at <a href="http://redhat.com" target="_blank">redhat.com</a>> wrote:<br>
> > On Tue, Jan 27, 2015 at 02:10:17AM +0100, Csaba Henk wrote:<br>
> > > Does it mean that the implementation of feature would essentially boil<br>
> > > down<br>
> > > to an auth ruleset calculated by glusterfs?<br>
> ><br>
> > I guess that depends on the goal of the feature. Where does the need<br>
> > arrise to "turn off the glusterfs protocol"? Should nothing outside of<br>
> > the trusted storage pool be able to connect to the bricks? This would<br>
> > effectively only allow NFS/Samba/... when the service is located on a<br>
> > system that is part of the trusted storage pool.<br>
><br>
> So, the basic use case is when in a cloud environment we make a Gluster<br>
> volume (entirely or partially) accessible via Gluster-NFS. Then the NFS<br>
> server is part of the Gluster cluster and a simple semantics of "turn off<br>
> glusterfs proto" (involving the earlier discussed internal exceptions)<br>
> seems to do the job (for preventint uncurated access).<br>
<br>
</span>Ok.<br>
<span class=""><br>
> However, a variant of that -- which is supposed to become more prevalent<br>
> -- is when the Gluster volume is made accessible with the help of<br>
> NFS-Ganesha. The Ganesha server typically resides outside of the<br>
> cluster, but should be handled as a trusted entity. That is, we still<br>
> need a simplistic semantics which lets us (cloud integrators) to be<br>
> assured that uncurated glusterfs access is prevented, but we need to<br>
> allow execptions for the occasional external trusted entity.<br>
<br>
</span>The High-Availability NFS-Ganesha design puts the NFS-Ganesha service in<br>
the trusted storage pool, possibly on the servers hosting bricks. Maybe<br>
you can comment on why this is not suitable or wished for in your<br>
environment? This design basically swaps Gluster/NFS for NFS-Ganesha.<br>
<br>
<a href="http://www.gluster.org/community/documentation/index.php/Features/HA_for_ganesha" target="_blank">http://www.gluster.org/community/documentation/index.php/Features/HA_for_ganesha</a><br>
<span class=""><br>
> Furthermore, the one who knows of these (transient) execptions is<br>
> (the admin of / some component of) the cloud, so their management<br>
> should also happen from the cloud side. That led me to asking about<br>
> "gluster volume set". (Anyway, the model case, turning of gluster<br>
> NFS, is also managed from the cloud side by "gluster volume set".)<br>
<br>
</span>I'm not sure if you're talking about this?<br>
<br>
<a href="http://www.gluster.org/community/documentation/index.php/Features/Gluster_CLI_for_ganesha" target="_blank">http://www.gluster.org/community/documentation/index.php/Features/Gluster_CLI_for_ganesha</a><br>
<br>
At the moment, I think that also assumes the NFS-Ganesha service is<br>
running inside the trusted storage pool. If you need any of those<br>
functions available outside of the trusted storage pool, get in touch<br>
with the feature owners and keep the gluster-devel list on CC.<br>
<br>
Thanks,<br>
Niels<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br></div>