[Pvfs2-developers] RFC: Config file overhaul

[Rob Ross]

I feel like the HUP should be a full server restart?

Clients don't have a way to know that they need to reload the config 
file, currently. Likewise, since someone could just kill the server and 
then restart with a totally different config file, I don't think that we 
want to try to enforce any rules on what parameters may be changed. This 
is just a convenient way to reload, right?

Rob

Phil Carns wrote:
> I have a few questions about some details of the implementation:
> 
> - What exactly will a HUP do on the server side?  For example, is this 
> pretty much a full server restart, a restart of the I/O components 
> (job/trove/bmi/etc.), or just selectively reseting parameters that can 
> be changed dynamically?
> 
> - How will a reload of the configuration affect clients that already 
> have the file system mounted?  They typically have already read and 
> parsed the configuration locally.  Do they continue with the previous 
> configuration or do they get the updates as well?
> 
> - This sort of depends on the answers to the previous questions, but is 
> there any restriction on what configuration parameters can actually be 
> changed on the fly?  There are some obvious ones that cannot be changed 
> (fsid, root handle, range ownership, etc.).  Are there any others?  Do 
> we need anything to protect against this or just document what 
> parameters are off limits?
> 
> 
> FWIW, I agree with the direction that you guys are now heading with this 
> stuff for the near future.  The dependence on a particular servers being 
> around for startup and use of things like portmapper would cause 
> problems for our environment.  We have to worry a good bit about 
> firewalls, and asymmetric servers would make it harder to play nice with 
> failover software.
> 
> -Phil
> 
> 
> 
> Rob Ross wrote:
>> Hi all,
>>
>> Since I'm being discussed, I thought that I should chime in :).
>>
>> I agree that what we're talking about here is just a couple of steps 
>> in the right general direction, not where we would really like to be 
>> in the long run.
>>
>> The zero-conf concept sounds great to me, conceptually. However, I 
>> don't want to have an implementation of that that forces us into a 
>> dependence on a particular server for startup. More discussion might 
>> change my mind? I dunno.
>>
>> Server-to-server (s2s) seems like the right way to do the config file 
>> verification in the long term. However, the code we're going to use to 
>> do that is just now shaping up. So we're not quite ready to do that yet.
>>
>> So, I proposed (off-line) that we do this interim thing for now (which 
>> cleans things up quite a bit) and continue thinking and talking about 
>> how we might like the system to work in the longer term.
>>
>> Regards,
>>
>> Rob
>>
>> Murali Vilayannur wrote:
>>
>>> Hi pete,
>>>
>>>> I thought with your discussion of getconfig/putconfig that you were
>>>> implicitly planning to get server-to-server communication to work
>>>> too.
>>>
>>>
>>> I was planning on doing that. But it fizzled out because of RobR's 
>>> concern
>>> about scalability and dependence on a single root server..
>>>
>>>> What you describe here sounds like fine stuff.  And if later
>>>> somebody gets ambitious and wants to do more "zeroconf"-ish work,
>>>> they can build on this.  Thanks for the explanations.
>>>
>>>
>>> Yep. Exactly. I hope so too :)
>>> thanks!
>>> Murali
>>> _______________________________________________
>>> Pvfs2-developers mailing list
>>> Pvfs2-developers at beowulf-underground.org
>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>>
>> _______________________________________________
>> Pvfs2-developers mailing list
>> Pvfs2-developers at beowulf-underground.org
>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>