[Gluster-devel] How do we identify peers?

Kaushal M kshlmster at gmail.com
Wed Jun 26 06:37:40 UTC 2013


Forgot the link to the bug,
[1] https://bugzilla.redhat.com/show_bug.cgi?id=890502
Comment 2 in particular shows all the described problems

On Wed, Jun 26, 2013 at 12:06 PM, Kaushal M <kshlmster at gmail.com> wrote:
> Hi all,
> We have a problem with how we identify peers in GlusterFS which we
> need to solve.
>
> Peers in GlusterFS are currently identified using two keys.
>  - the address of the peer (hostname/ip)
>  - a UUID
> The address is used as an identifier in the gluster cli commands and
> is the key visible to the users of glusterfs. The UUID is used
> internally by glusterd to identify peers.
> This approach works well when we are using glusterfs on systems with
> single network interfaces and when we are using a hostname as the
> address. We run into problems when we multiple network interfaces are
> involved or if hostname and ips are mixed in gluster cli commands.
> Bug-890502 [1] is a good example of the problems we have. This bug
> involves usage of multiple interfaces as well as mixing of
> hostname/ip.
>
> We need to come up with a good solution to this which would solve this.
>
> Some of the solutions that have been thought of are below.
>
> 1. Continue with the current implementation of using UUID internally
> and addresses externally, but provide a good translation interface
> which will translate a given address into UUID correctly. The
> translation interface might involve some network requests which could
> increase the time taken for command execution.
>
> 2. Use the UUID itself both internally and externally, and have a
> command for associating a list of addresses with a UUID. The downside
> is that typing out UUIDs is unwieldy and users will need users to
> execute more commands.
>
> 3. Similar to 2, but use an alias for the peer externally instead of
> the UUID. This will need an additional mechanism to specify the alias
> for a peer. This approach will need users one additional command
> compared to approach 2, but the other commands will be simpler to
> type.
>
>
>
> What are your thoughts about the problem and the proposed solutions?
> If anyone has any questions regarding the problem or the solutions, or
> if there is a better solution, please sound off.
>
> Thanks,
> Kaushal




More information about the Gluster-devel mailing list