[Pvfs2-developers] Re: unifying config files

Rob Ross rross at mcs.anl.gov
Wed Jun 20 21:48:49 EDT 2007


i think of zeroconf as just a way of identifying a server from which to 
obtain a config file (which could be text). in other words, we could 
distribute our *existing* config files via zeroconf plus a getconfig.

rob

Sam Lang wrote:
> 
> On Jun 20, 2007, at 7:54 PM, Rob Ross wrote:
> 
>> Since our config file is text, can't we skip any encoding? I agree 
>> that it would be more concise, but we don't send config files around 
>> all that often.
> 
> With zero conf they would be generated on the fly, so a text format 
> isn't really necessary, and would be harder to update change than an 
> internal struct representation that we just encode/decode.
> 
> -sam
> 
>>
>> Rob
>>
>> Sam Lang wrote:
>>> On Jun 20, 2007, at 1:54 AM, Murali Vilayannur wrote:
>>>> Hi Sam,
>>>> I see..So do you wish that we fallback to parsing from server config
>>>> file if that were to be specified in place of a server-alias string in
>>>> command line..
>>>> That shouldn't be too hard, no?
>>> Hmm...well if the server config file isn't specified, why can't the 
>>> server just get the hostname instead of requiring an alias?
>>> 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.
>>>> Any updates on what the current stance on zero-conf based server
>>>> startups, i.e. is there still any interest and/or preferred
>>>> approaches? :)
>>> 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.
>>
> 


More information about the Pvfs2-developers mailing list