[Pvfs2-developers] Re: unifying config files

[Rob Ross]

We need multiple servers per node for failover.

I hate to require TCP/IP just for configuration.

Rob

Sam Lang wrote:
> 
> 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>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
> 
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>