[Pvfs2-developers] RFC: Config file overhaul

[Phil Carns]

Ok- just kinda checking to make sure of what you guys had in mind.  If 
the HUP is a full restart of the server, then it will complain on its 
own if the config file doesn't match what's in the storage space, so 
that isn't really a danger.  It also means that pretty much any tuning 
parameter is legal to change since all of the I/O components will be 
starting from scratch.

Just a heads up on one detail- we need to make sure that the server 
keeps its pid on the HUP or else updates its pidfile so that monitoring 
scripts don't get confused.

I think that leaving the client configuration alone is fine.

-Phil

Rob Ross wrote:
> 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
>>
>>