Without being expert in either tool, I believe that the feature Naryan
Desai is claiming for bcfg2 which he believes is not present in Puppet
is the ability to take a machine that does not conform to its prescribed
configuration, and then to tell bcfg2 "Hey, the way it is is the way I
want it; so slurp up the differences you see and record them as a new
way to be correct."
Suppose someone installs an OS variant that enhances /etc/hosts so that
it can also include IPv6 addresses, and then puts a bunch of IPv6 lines
in there. If I understand correctly, bcfg2 would see all that
gobbledygook and report "/etc/hosts is wrong in the following way...".
To which I, the admin, could respond by saying: "Bcfg2: for this
machine, you are to remember that the file is supposed to be just like
it is now." Bcfg2 stores the file without any inspection or
"understanding" of it, except that those are the bytes that should be in
/etc/hosts for that machine. Whereas for Puppet, I may have to enhance
the object which represents a host so that it has a new IPv6 address
attribute, along with an enhancement of the method that translates host
instances into /etc/hosts lines. I believe the "reversability" claimed
for bcfg2 is the ability to go from existing client configuration into
bcfg2 policy rather than the normal policy to configuration direction.
Because Puppet "understands" more about /etc/hosts, it can reason about
it more adroitly; but it also may take longer to support innovations.
The respective authors of their tools should now correct my
misapprehansions.
- Stephen
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
