[Pvfs2-developers] Re: unifying config files

[Sam Lang]

On Jun 20, 2007, at 11:38 AM, Murali Vilayannur wrote:

> Hi Sam,
>
>> Hmm...well if the server config file isn't specified, why can't the
>> server just get the hostname instead of requiring an alias?
>
> hmm.. For one that may not work if you run multiple servers on the  
> same machine
> since their hostnames would be identical, no?

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.

>
>>
>> Yeah I was thinking that if a server config was specified as the
>> second argument to the pvfs2-server, the server would go ahead and
>> use those values for endpoint, storage location, logfile, etc.
>
> We could still keep all the old code intact and do this parsing if you
> are worried that people's scripts etc would break.

Maybe its not a big deal -- and we make people change their scripts  
and config files.  That's certainly easier/cleaner.

>
>>
>> Definitely still interest.  I'm not sure we've come up with an
>> approach yet.  I would argue a first step toward zero conf would be
>> encoding/decoding the config using the lebf encoding layer.  This
>> would give us a more efficient representation of the config, as well
>> as make it easier to modify at runtime.
>
> I was thinking of a very simple approach.
> All machines run portmapper & support tcp/ip (especially since they
> presumably also require NFS)..

I don't know about NFS being required, but requiring tcp/ip is  
probably ok.

> How about if we write a simple RPC stub with a fixed PVFS specific
> program number and export a single interface to push the config file
> and aliases to all servers?
> Servers startup will create a thread that binds to any available port,
> registers the port, program number with portmapper and prevents any
> further initialization until it gets the config file params.
> We write a tool that pushes these to each server by querying the
> portmapper for the port.
> Pushing such values is implicitly a SIGHUP equivalent. The server
> reloads/parses its config files and sets itself up. The RPC thread
> continues to listen for updates on the ephemeral port in the meantime
> until the server process dies..

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.

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.

-sam

> thanks,
> Murali
>
>>
>> -sam
>>
>> > thanks,
>> > Murali
>> >
>> > On 6/19/07, Sam Lang <slang at mcs.anl.gov> wrote:
>> >>
>> >> Hi Murali,
>> >>
>> >> Just never got around to commit it.  My only complaint is that it
>> >> doesn't allow the server to optionally take a server config  
>> file (for
>> >> legacy scripts, etc.).  I think that might be hard to implement
>> >> though...
>> >>
>> >> -sam
>> >>
>> >> On Jun 20, 2007, at 1:19 AM, Murali Vilayannur wrote:
>> >>
>> >> > Hey Sam,
>> >> > Any interest in merging this patch to unify config files while
>> >> > starting up pvfs2 servers?
>> >> > I have reworked it against HEAD..
>> >> > Relevant thread..
>> >> > http://www.beowulf-underground.org/pipermail/pvfs2-developers/ 
>> 2007-
>> >> > February/003209.html
>> >> > thanks,
>> >> > Murali
>> >> > <unify-config-files.patch>
>> >>
>> >>
>> >
>>
>>
>