[Pvfs2-developers] Re: unifying config files

[Rob Ross]

I agree Murali that this is getting handwavy w/out a prototype.

We've got a couple of different topics mixing too :).

One is discovering available servers. It seems like zeroconf/mdns seems 
like a reasonable way to do this, at least when UDP works.

Another is just coming up with a way to distribute the config file to 
servers w/out copying it. This could be done with a getconfig (by the 
server, rather than client) if a server can identify an already running 
server in the system (perhaps with zeroconf).

Last is dynamically changing configuration. This is a serious change...

Rob

Murali Vilayannur wrote:
> Sam,
>>
>> That's true.  The multiple servers per node stuff was added to
>> genconfig just for debugging.  I can't think of any good uses for
>> that in practice.  Are there?  If not, we might be able to get away
>> with just using a -p <port> argument in cases where multiple servers/
>> host is desired.
> 
> If a single node has multiple cpus and multiple disks, it may not be a 
> bad idea
> to run multiple server processes on it..
> I guess the alias is in some ways a succint abbreviation of what host,
> port and interface
> a server process is designed to run on, no?
> 
>>
>> Maybe its not a big deal -- and we make people change their scripts
>> and config files.  That's certainly easier/cleaner.
> 
> Indeed :)
> 
>> This is an interesting idea, and allows us to leverage infrastructure
>> that's already on most systems.
>>
>> It seems just as easy though to give each server a master endpoint to
>> send his host,port,etc. config info there.  That avoids a tcp/ip and
>> portmapper dependency doesn't it?  There's a startup issue, but
>> servers could retry until they succeed.
> 
> yep; definitely. The only problem with this approach is that we don't
> have a standardized port number on which to query on..
> Hold on..
> Sigh..actually I now realize why I hadnt ventured on this track originally.
> We could have multiple server processes on the same physical node
> and we cannot do the standard master endpoint port technique or the 
> portmapper
> technique since portmapper cannot deal with multiple ephemeral ports
> for a single
> RPC program number..
> We could do the following trick for the multiple server case on same node..
> Have a range of program numbers that are typically unallocated on a
> regular Linux
> distro and keep retrying until some program number <-> port
> registration succeeds.
> The admin tool will scan for port numbers on a set of machines for the
> program number
> ranges and push the config file information and alias information..
> I think it is all getting a little handwavy without any prototype..
> What do you guys think?
> 
>>
>> It also alleviates the need to have an admin tool that queries all
>> the portmappers on all the hosts for all the server ports, and pushes
>> that info back to all the servers.
> 
> This is not that big a deal, is it? I am trying to understand how we
> can make it zero-conf
> without telling the system something :)
> thanks,