Bogdan Costescu wrote:
On Tue, 30 Sep 2008, Eric Thibodeau wrote:
This has given me much flexibility and a very fast path to upgrade
the nodes (LIVE!) since they would only need to be rebooted if I
changed the kernel. I can install/upgrade the node's environment by
simply chrooting into it and using the node's package manager and
utilities as if it were a regular system).
Only the first is an advantage of using NFS-root; the second is shared
by most methods that use a node "image".
More or less, NFS-root changes are "propagated" instantly, most other
approaches require a re-sync. Another way to see this, the NFS root
approach only does changes on the head node and changed files don't need
to be propagated and are accessed on a as-needed basis, this might have
significant impacts on large deployments....not that I suggest that they
use this approach ;)
However random installations or modifications of configuration file
within the chroot become very difficult to reproduce when you build
the next node "image"
Document document document...which no one does...but document.
- either scripting everything or using cfengine/puppet/etc. can save a
lot of time in the long run, despite the initial effort to set up.
I'll take your word for it that they have a version tracking mechanism.
But I am in a special case where, if I break the cluster, I can fix
it quickly and I always have a backup copy of the boot "root" image
ready to switch to if my fiddling goes wrong.
Why not keeping several "images" around and only point the nodes to
mount the one considered current or "good" ?
Well, that's what I meant... probably not clearly. ;)
Eric
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
