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