On 27/06/2013, at 6:53 PM, Anand Avati wrote: > Using UUIDs as the identifier for all internal management communication is a > good idea. The CLI commands could still use hosts or IPs, but that should be > translated to UUIDs as an alias as superficially as possible (ideally in the > CLI itself, glusterd only communicates by UUID). The translation of UUID to > host IPs should really be dynamic/discovery based. Each host must present all > its IPs to all its peers.
Seriously bad idea (after thinking about it). :) In corporate environments, the "backup network" which most places have for their servers is *only* for backup traffic. Applications on the server (such as Gluster) get their own dedicated nics and switches. > Volgen and protocol/client must be enhanced to accept multiple IPs for each > brick and auto select the right/routed address at runtime (or accept a > preferred interface as input). Have you looked at the connection group stuff? I think that would be a more flexible approach for most corporate/enterprise level environments. That being said, an auto selection mechanism might really be the way to go for cloud scale stuff (unsure). :) > We should even start identifying bricks by UUID and self-discovered > (independent of host and backend mount-point). This way if an EBS volume is > detached and attached to a different node at a different backend mount, > configuration must get auto reconfigured (either completely using udev, or > with partial/limited input from admin). Converting to UUID would be partial > if bricks are not pulled in to the scheme. Hmmm, interesting thought. Prob want SSL certificates in use for this, but that wouldn't be a blocker. Not see-ing this approach as being easily code-able in the near future though? More a longer term thing? Regards and best wishes, Justin Clift -- Open Source and Standards @ Red Hat twitter.com/realjustinclift _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
