On 28/06/2013, at 3:56 AM, Ian Latter wrote:
snip
Let's take the grouping proposal for example - what's the difference between
the proposed (a host UUID plus a group/interface identifier) and a
per-interface alias?
node1.gluster.org 10.1.1.100 6b481ebb-859a-4c2b-8b5f-8f0bba7c3b9a-group1
On 06/28/2013 12:37 AM, Anand Avati wrote:
On Wed, Jun 26, 2013 at 8:04 AM, Jeff Darcy jda...@redhat.com
mailto:jda...@redhat.com wrote:
On 06/26/2013 11:42 AM, Joe Julian wrote:
There are only two translators that use the network, server and
client. I'm unclear how these
On 06/26/2013 11:42 AM, Joe Julian wrote:
There are only two translators that use the network, server and
client. I'm unclear how these communication groups would get
applied.
I lean a little bit toward being against solving network problems
with application complexity. Can't these problems be
On 06/27/2013 09:37 AM, Stephan von Krawczynski wrote:
On Wed, 26 Jun 2013 11:04:07 -0400 Jeff Darcy jda...@redhat.com
wrote:
[Jeff on UUIDs]
I generally vote against using UUIDs and for IPs. In runtime I can
easily switch an IP in a replacement situation, but can I switch a
UUID in the same
On Wed, 26 Jun 2013 11:46:36 -0400
Jeff Darcy jda...@redhat.com wrote:
On 06/27/2013 09:37 AM, Stephan von Krawczynski wrote:
On Wed, 26 Jun 2013 11:04:07 -0400 Jeff Darcy jda...@redhat.com
wrote:
[Jeff on UUIDs]
I generally vote against using UUIDs and for IPs. In runtime I can
On 06/27/2013 10:30 AM, Stephan von Krawczynski wrote:
On Wed, 26 Jun 2013 11:46:36 -0400
Jeff Darcy jda...@redhat.com wrote:
On 06/27/2013 09:37 AM, Stephan von Krawczynski wrote:
On Wed, 26 Jun 2013 11:04:07 -0400 Jeff Darcy jda...@redhat.com
wrote:
[Jeff on UUIDs]
I generally vote
On 06/27/2013 10:58 AM, Stephan von Krawczynski wrote:
On Thu, 27 Jun 2013 10:37:23 -0400
Joe Landman land...@scalableinformatics.com wrote:
No. One of the largest issues we and our customers have been having for
years has been tightly tying gluster volume creation to single IP
addresses.
On 06/27/2013 08:10 AM, Stephan von Krawczynski wrote:
On Thu, 27 Jun 2013 07:47:18 -0700
Joe Julian j...@julianfamily.org wrote:
I hear what you're saying, but I can't see that as a valid design to
provide future growth and to regain the flexibility that I believe you
enjoyed when we used to
On Wed, Jun 26, 2013 at 8:04 AM, Jeff Darcy jda...@redhat.com wrote:
On 06/26/2013 11:42 AM, Joe Julian wrote:
There are only two translators that use the network, server and
client. I'm unclear how these communication groups would get
applied.
I lean a little bit toward being against
On 27/06/2013, at 8:07 PM, Anand Avati wrote:
snip
To figure out which connection a client has to use, we could do auto-discover
at the time of GETSPEC depending on which network interface the GETSPEC
request is coming in from. We already have per transport client volfiles (one
for tcp, one
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
On Thu, Jun 27, 2013 at 1:16 PM, Justin Clift jcl...@redhat.com wrote:
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
Darcy jda...@redhat.com
To: Stephan von Krawczynski sk...@ithnet.com
Subject: Re: [Gluster-devel] RFC - Connection Groups concept
Date: Wed, 26 Jun 2013 11:46:36 -0400
On 06/27/2013 09:37 AM, Stephan von Krawczynski wrote:
On Wed, 26 Jun 2013 11:04:07 -0400 Jeff Darcy jda...@redhat.com
wrote
From: Anand Avati anand.av...@gmail.com
To: Jeff Darcy jda...@redhat.com
Subject: Re: [Gluster-devel] RFC - Connection Groups concept
Date: Thu, 27 Jun 2013 12:07:36 -0700
On Wed, Jun 26, 2013 at 8:04 AM, Jeff Darcy jda...@redhat.com wrote:
On 06/26/2013 11:42 AM, Joe Julian wrote
Hey all,
This is an idea that's been on my mind for a while, to overcome a
fundamental problem Gluster has with some network common topologies.
(thanks to Niels de Vos for letting me bounce ideas off him btw)
Most corp places I've worked have multiple network interfaces on their
storage boxes,
On Wed, 26 Jun 2013 08:46:35 +0100
Justin Clift jcl...@redhat.com wrote:
Hey all,
This is an idea that's been on my mind for a while, to overcome a
fundamental problem Gluster has with some network common topologies.
(thanks to Niels de Vos for letting me bounce ideas off him btw)
Most
On 26/06/2013, at 9:28 AM, Stephan von Krawczynski wrote:
snip
This is an idea that's been on my mind for a while, to overcome a
fundamental problem Gluster has with some network common topologies.
(thanks to Niels de Vos for letting me bounce ideas off him btw)
Most corp places I've worked
On 26/06/2013, at 4:42 PM, Joe Julian wrote:
There are only two translators that use the network, server and client. I'm
unclear how these communication groups would get applied.
Yeah, how this would affect things definitely needs to be worked out. :)
I lean a little bit toward being
18 matches
Mail list logo
