>>>>> "Luke" == Luke Kanies <[EMAIL PROTECTED]> writes:
Luke> So, does bcfg2 use probes or not? If so, what is the purpose Luke> of these probes? Do these probes affect the configuration in Luke> any way? They do, but are treated as different data than the server side specification. It is explicitly tagged as dynamic. I honestly think that this aspect of both tools is pretty comparable. >> The data that you use in the language is much finer grained than >> what we use in bcfg2. That makes a big difference in how >> reversible your configuration is to your specification. Bcfg2 >> gets a _lot_ out of being able to produce spec from a client. Luke> I don't understand what you mean by reversibility. That is, I Luke> don't understand what granularity has to do with it. I can Luke> isomorphically transform between a Puppet configuration and a Luke> system pretty trivially[1], backwards or forwards -- is that Luke> "reversibility"? If so, how is Puppet lacking it? Here is the problem. Puppet's model is fine-grained. That means that as a part of the abstraction layer you have made a series of decisions about how particular objects interact with the system. (how crontab entries are made, what it means to be a user, etc) The more complex these objects are, the more likely it is that a user making manual changes may not follow these policies. In simple cases it is alright, but can go awry when you object doesn't support the full range of options that a crazy admin may want to use. For example, cluster systems typically add and drop login perms as jobs are scheduled on particular nodes. I would not be surprised if your user object didn't already support this. It is not enough for objects to be extensible, since you can encounter these cases without realizing it up front. So far, this discussion has largely focused on per-entry reversibility, but this is actually the smaller part of the problem. The next step is to have some confidence that the client configuration is actually representative of that client. This involves the use of heuristics, so it will never be perfect. The quality of the heuristics will necessarily decrease with the granularity of the specification language, since you can have several discrete objects that are combined to form an observed result. Reversing this process is possible, but is quite difficult. My point is that building a reversible model using a fine-grained language is difficult, and could not likely be done in a portable, robust way. This is true for you, LCFG, and any other tool that uses this model. <snip> Luke> Actually, no; frankly, I don't particularly care about the Luke> sysadmins in the long term. It is my belief that if I build Luke> an abstraction layer, the developers will come and bring Luke> better tools for managing systems. I *know* that Puppet's Luke> language isn't the end-all/be-all, but it's my sacrifice bunt Luke> just to get the library out there. As I've said before, I am Luke> focused on the developer-oriented sysadmins, not the Luke> mechanics. Puppet supports both, but my long-term goals are Luke> definitely developer-oriented. Luke> People are consistently creating tool silos, and I'm tired of Luke> it. I'm doing my best to create a system that both functions Luke> as a competent tool and can function as a base layer to much Luke> better tools, which I wouldn't expect to write. We are both working towards similar goals, but have picked different approaches; again, I think this is fine. The decisions we have both already made have closed some doors and opened others. I didn't realize that you were targeting developers over sysadmins so explicitly; this is a clear difference in approaches between puppet and bcfg2. Luke> Heh, and you were the one complaining to me about Luke> release-early-and-release-often. :) It turns out to be a pretty complicated issue. Sysadmins don't like it when you break their systems. >> On the point that you are disputing, I am not convinced that you >> are right. I have a pretty good understanding of what it takes to >> implement these features in a robust way. Luke> See, that's insulting. Your use of the word "robust" here is Luke> a clear indication that you think that even if I implemented Luke> the features, they wouldn't be robust. I didn't intend this as a personal slight. I just meant that several of the design decisions that you have already made in puppet would make it quite hard to make this sort of operational mode work well, if at all. There are decisions that I have made in bcfg2 that have made it harder to implement particular types of features; that is just the name of the game. -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
