Bug 831699

This is kind of a continuation of our long-standing problem with names vs. IPs for identifying cluster nodes.  Configurations with separate front-end and back-end networks are becoming ever more common, and users are often running into some predictable problems.  For today's example, see the following ridiculous URL.

http://community.gluster.org/q/we-have-a-glusterfs-3-3-system-using-a-10gbe-san-being-mounted-by-clients-on-a-1gb-san-the-peers-are-all-on-192-168-12-0-24-however-the-clients-are-on-192-168-10-0-24-with-no-access-to-192-168-12-0-24-is-there-anyway-to-mount-this-using-the-mount--t-glusterfs-rather-than-nfs-it-looks-like-the-peer-ip-is-pushed-to-the-client-which-then-can-t-reach-those-ips-and-fails-can-i-have-two-ips-listed-per-glusterfs-node-on-different-networks

What I propose is that we add a new command (and underlying infrastructure) for "gluster peer alias OLD_NAME_OR_ADDR NEW_NAME_OR_ADDR [public|private] [primary]".  This allows users to manage aliases themselves, instead of e.g. having names supersede addresses as a side effect of "peer probe".  The public/private/primary options have the following meanings.

* A name/address marked "public" will *not* be used for internal cluster communication.

* A name/address marked "private" will *not* be presented to clients e.g. as the remote-host value for a protocol/client translator.

* Among the names/addresses that are valid for a particular purpose, the one marked "primary" (if present) will be used unless overridden.  For example, servers will generally probe one another using the primary address, but "gluster peer probe $not_primary_address" will override that.

Long term, we might need to deal with multiple address groups instead of just public/private, perhaps tied into multi-tenant identities and more complex policies, all the way up to something almost like a VLAN.  This proposal is merely an intermediate step to address the needs that seem to exist in the field today.