[Gluster-devel] RFC - "Connection Groups" concept

[Joe Julian]

On 06/27/2013 07:30 AM, Stephan von Krawczynski wrote:
> On Wed, 26 Jun 2013 11:46:36 -0400
> Jeff Darcy <jdarcy at 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 <jdarcy at 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 easy manner?
>> I don't see why that would be problematic.  The UUIDs we're talking
>> about aren't tied to hardware.  They're essentially big random numbers
>> we assign ourselves.  IIRC they're just stored in a file, so they can be
>> trivially copied from a system to its replacement.  The problem is
>> precisely that DNS names and IP addresses aren't good *system*
>> identifiers.  For one thing, they refer to interfaces rather than
>> systems (which might have many interfaces).  For another, even that
>> association is too transient.  Such IDs are convenient for referring to
>> a system *at a specific point in time* but not permanently, and a
>> permanent ID for the whole system is something we really need.  It sure
>> would be nice if the networking community would stop ****ing around when
>> it comes to multi-homed or mobile hosts, but they don't seem inclined to
>> so the rest of us have to fall back on other established patterns for
>> identifying hosts separately from their addresses.
> Now the exact reason why IPs are always better than your idea of UUIDs is
> because they are linked to interfaces. You _want_ your fs node to use exactly
> _this_ interface and not _some_ interface because you then have a real chance
> to direct your traffic like you want it and not like glusterfs currently
> thinks could be best.
> And whereas for IP replacement there are good and working examples and tools
> UUID-replacement has zero options at this time for replacement procedures.
> What happens if there are two nodes at some short period with the same UUID?
> All you do with UUIDs is open yet another box owned by Pandora (again) right
> in the midst of nowhere while at the same time there is still no valid public
> document how someone can import his existing data in glusterfs without copying
> it and getting it out again without copying or damaging it.
> Why not begin at the very start of the operation with clearing things up?
> Maybe I am just not mainstream any more wanting only a redundant and safe file
> service with easy migration. Maybe glusterfs has become something else in the
> meantime which I simply do not understand...
> glusterfs on a mobile host as mainstream implementation idea, gimme a break.
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 write vol files. The server needs to be 
identified in an abstract way so the network and anything else can be 
managed around its existence. A brick should belong to that server, not 
to an ip address.

Network re-configurations happen. Servers get renumbered. Most of us 
can't afford downtime, which is why glusterd and the cli were created. 
We needed this live-configuration tool to do that. (Configuration 
changes without downtime was the #1 most requested feature). Yes, I 
wrote volfiles under 2.0. The current cli is an improvement, even though 
it offers less flexibility. The way to get back that flexibility is to 
design clear object based configurations which can then have methods 
assigned to them to extend those abilities. Part of that is defining 
objects.

A server is an object that has bricks and network interfaces. It is 
logical to identify the server uniquely as well as the interfaces and 
the bricks.

This has nothing to do with mobility, it has to do with scaleability 
which addresses a very strong need.