[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