Steven W. Carter wrote:
Actually, from what I've been able to tell, Puppet + Cobbler is
exactly how the stateless project handles the configuration of the
diskless hosts.
you're right, if I understood this
http://fedoraproject.org/wiki/StatelessLinux/CreateClientImage, you can
have a cobbler profile that doesn't install anything (no kickstart) and
runs a distro from a read-only nfs exported filesystem - cool; I guess I
just assumed otherwise.
I'm trying to figure out now if the capsule is just a different
interpretation for the same thing... the capsule is actually sent
(copied) to the nodes and the root filesystem will be in a ramdisk (e.g.
the root filesystem doesn't have to be read-only, it can be changed in a
node without affecting the others or the original), but apart from that,
it seems that the answer to the original question is that there's
nothing perceus does that cobbler doesn't.
Does anyone use or know of uses of cobbler in hpc clusters with
stateless nodes?
miguel
On Thu, Aug 7, 2008 at 7:04 PM, Miguel Costa
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Michael DeHaan wrote:
Miguel Costa wrote:
Michael DeHaan wrote:
I use cobbler to provision xen guests and perceus
(http://www.perceus.org) to provision stateless images on
nodes of hpc clusters, which are probably different from thin
clients only in the use they are given :). From where I stand,
it would be great if cobbler could manage something similar (I
guess that's why I'm on both these lists :) )
What does Perceus do that Cobbler does not in your usage?
well, in a nutshell, at least the way I use them (I might me
missing some feature)
cobbler: I create profiles, which are essentially managed
kickstarts, and assign them to systems. When this system boots
from pxe (or is created by koan --virt), it gets installed
according to that profile. I usually use cobbler only once per
system.
perceus: I create "capsules", which are stateless system images,
and assign them to nodes. When the nodes boot from pxe, the
capsule is transferred to the node, where it runs from ram (so
the node can be diskless). Perceus is used every time the nodes
boot.
With systems provisioned with cobbler, the result is a bunch of
independent systems, which without other configuration
management tools will each follow their own way, at least until
they are reinstalled. For xen guests, this is precisely what I
need, since each system is used for different purposes.
With nodes provisioned with perceus, the configuration is
controlled by the capsule which resides on the server. I just
change the capsule on the server and push the changes to the
nodes, or reboot the nodes for more drastic changes. The bottom
line is that I only manage two systems, the server and the
capsule, which just happens to run on a large number of nodes.
For a hpc cluster, this is precisely what I need, since each
node is used only to compute and send results home.
In this case, the capsule seems very analogous to a config
management profile that Stateless Project was attempting,
right? I'm probably missing some of the finer points. If I
am, can you explain further?
FWIW I recently shot out an email to Cobbler-list about having
cobbler dynamically generate the external_nodes information for
Puppet, so it will make it easier to link cobbler profiles with
puppet profiles. Look for that in a future release. If that's
unrelated that's ok :)
From the little I saw of puppet, yes, I think it achieves the
same effect (stateless), and probably in a more effective manner,
but I guess the best way to see the difference is to look at the
diskless case. You can't manage diskless nodes (or thin clients,
etc.) with cobbler + puppet, can you?
This is just to illustrate what I think is different in the two
approaches - in practice, nodes/thin clients/etc. usually have
some kind of non-volatile memory, so if cobbler + puppet achieve
the same effect with less network usage and faster boot times, all
the better
miguel
P.S. capsules also allow us to boot different versions or
distributions at will, without reinstallation - something like a
repository of livecd images that boot from the network. This
doesn't sound very useful, but one can think of situations where
machines are used for different purposes at different times, e.g.
as desktops during the day and compute nodes during the night,
where this kind of separation might have some advantages
Perceus doesn't have a web interface though :)
miguel
--Michael
_______________________________________________
Stateless-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/stateless-list
