>>>>> "Stephen" == Stephen P Schaefer <[EMAIL PROTECTED]> writes:
Stephen> Without being expert in either tool, I believe that the Stephen> feature Naryan Desai is claiming for bcfg2 which he Stephen> believes is not present in Puppet is the ability to take a Stephen> machine that does not conform to its prescribed Stephen> configuration, and then to tell bcfg2 "Hey, the way it is Stephen> is the way I want it; so slurp up the differences you see Stephen> and record them as a new way to be correct." You're on the right track here, but let me slightly refocus your comments. The feature you are describing here is an application of reversibility. The bcfg2 client and server do not use the specification language to communicate. They use a simple language with very few object types to communicate. This language is reversible. Stephen> Suppose someone installs an OS variant that enhances Stephen> /etc/hosts so that it can also include IPv6 addresses, and Stephen> then puts a bunch of IPv6 lines in there. If I understand Stephen> correctly, bcfg2 would see all that gobbledygook and report Stephen> "/etc/hosts is wrong in the following way...". To which I, Stephen> the admin, could respond by saying: "Bcfg2: for this Stephen> machine, you are to remember that the file is supposed to Stephen> be just like it is now." Bcfg2 stores the file without any Stephen> inspection or "understanding" of it, except that those are Stephen> the bytes that should be in /etc/hosts for that machine. Stephen> Whereas for Puppet, I may have to enhance the object which Stephen> represents a host so that it has a new IPv6 address Stephen> attribute, along with an enhancement of the method that Stephen> translates host instances into /etc/hosts lines. I believe Stephen> the "reversability" claimed for bcfg2 is the ability to go Stephen> from existing client configuration into bcfg2 policy rather Stephen> than the normal policy to configuration direction. While this can be done, the key intuition is that a system that builds a larger, abstract interface will necessarily make a lot more assumptions about mechanisms (how are addresses configured in /etc/hosts, how are users created, how are cronjobs created). These mechanisms will be fragile when you allow users to make local modifications and then attempt to interpret them in the higher-grained language. The goal here is to support a model where you have a specification that can validate it against all current states so that you can understand: - Which hosts are out of spec - Why they are out of spec - What parts of the system are not reflected in the spec - How manual administrative actions should be integrated into the spec This isn't just a per-entry validation, this is more like a diff where you have added new source files to a directory. -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
