<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 1:16 PM, Justin Clift <span dir="ltr"><<a href="mailto:jclift@redhat.com" target="_blank">jclift@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 27/06/2013, at 8:07 PM, Anand Avati wrote:<br>
<snip><br>
</div><div class="im">> Another approach might be to just store the UUID of the host in the client volfile, as remote-uuid (instead of remote-host option). The client can query the mount server to resolve the UUID to a host at that point in time with a HOSTMAPPER service (like our PORTMAPPER server which maps bricks to ports). This hostmapper can maintain the relationship of all the host UUIDs in the trusted pool to all their respective interface IPs, and use the interface of the incoming mapping request to perform appropriate mapping. When in doubt, it can always return the entire set of IPs of a host (with transport types) and let the client figure out which of those IPs are routable and maybe even autodetect which is the fastest. E.g your server might have both 1g/e and 10g/e, and only some of your clients have 10g/e. In such cases this kind of auto discovery at mount time might be desirable.<br>
><br>
> Thoughts?<br>
<br>
</div>Potentially very dynamic, and less controllable. Could be a good way to go<br>
for cloud scale. :)<br>
<br>
The hostmapper idea is also interesting, because over time people could<br>
develop some very interesting algorithms for optimising that. Plugin<br>
model? :)<br>
<br>
It doesn't sound that optimal for some non-cloud-scale environments (I'm<br>
thinking some corporate/enterprise/government). The places I've personally<br>
worked have dedicated networks for things, and dynamic stuff like this<br>
could be a pita. (note "could" not "would be in every case")<br>
<br>
It would be nice if we could specify which network to use on a per volume<br>
basis for at least some volumes (eg "use the trusted network for volume X<br>
for PCI compliance"). But that doesn't necessarily preclude having other<br>
volumes select their networks automatically.<br>
<br>
Any ideas on how to work that into your concept too? :)<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div><br></div><div style>You can already do that by limiting allowing or rejecting access to each volume from a certain subnet (which can map to the subnet of the network you wish you rule in/out). Wouldn't that just work?</div>
<div style><br></div><div style>Avati</div><div style><br></div></div></div></div>