[Pvfs2-developers] Re: unifying config files

[Sam Lang]

On Jun 20, 2007, at 8:03 PM, Rob Ross wrote:

> 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...

But its the only interesting one. :-)  If the goal is to ease system  
administration, the first two don't seem all that worthwhile.   
Copying config files to nodes isn't a huge burden -- most likely the  
server binary has to be copied as well.  I agree that discovering  
servers doesn't require the versioning work that dynamic configs  
would, but it would still require an online modification of our  
config, so you're half way there anyway.

-sam

>
> 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,
>