On 27/06/2013, at 8:07 PM, Anand Avati wrote: <snip> > 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. > > Thoughts? Potentially very dynamic, and less controllable. Could be a good way to go for cloud scale. :) The hostmapper idea is also interesting, because over time people could develop some very interesting algorithms for optimising that. Plugin model? :) It doesn't sound that optimal for some non-cloud-scale environments (I'm thinking some corporate/enterprise/government). The places I've personally worked have dedicated networks for things, and dynamic stuff like this could be a pita. (note "could" not "would be in every case") It would be nice if we could specify which network to use on a per volume basis for at least some volumes (eg "use the trusted network for volume X for PCI compliance"). But that doesn't necessarily preclude having other volumes select their networks automatically. Any ideas on how to work that into your concept too? :) Regards and best wishes, Justin Clift -- Open Source and Standards @ Red Hat twitter.com/realjustinclift
