>>>>> "Luke" == Luke Kanies <[EMAIL PROTECTED]> writes:
Luke> From your email, they are far more similar than you think. Your comments in this mail don't really convince me of this. Luke> Further, it is entirely up to the sysadmin to use or ignore Luke> the Facter data. You use Puppet to write a program; your Luke> program can introspect the network to some extent, or it can Luke> declarate it 100%; that's a policy decision you have to make. These actually sounds equivalent. >> I can't really bring myself to get to deep into puppet's >> language. I get the same sinking feeling when I look at >> cfengine's language. They both don't seem to be describing things >> that I care about; the granularity seems wrong to me. I am >> probably not explaining it well; sometimes it is hard to >> completely describe visceral reactions. I guess that I feel like >> I am working in assembly. Luke> Once again, I'm floored; how do you specify a system's Luke> configuration without talking about the things on the system? Luke> Have you figured out a way within bcfg2 not to talk about Luke> users or groups or packages or services? Luke> As to granularity, you have to be granular somewhere, but the Luke> expectation (and my practice) is to separate the granular data Luke> and the association data. You create your classes and Luke> reusable components in one place, you associate them with Luke> nodes in another place. It's easy to say "this node is a Luke> webserver" without caring about what webserver means there. I Luke> don't see any essential difference between this and bcfg2. 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> Puppet operates in exactly the same way: Every element in the Luke> system is required to support retrieving the current state and Luke> setting the state, and Puppet's internal transactional system Luke> walks through the configuration comparing desired state to Luke> real state, syncing as appropriate. Not quite. You don't have a reversible configuration spec, so your tool can only talk about what you know; it can't talk about what it doesn't know so easily. Luke> The only difference I can see is that Puppet does not Luke> currently provide hooks for a sysadmin to selectively approve Luke> each change. However, you can selectively make any class, Luke> component, or element, or the whole system, run in dry-run Luke> mode, and it's so little code to add this user-selection that Luke> I'm going to add it to my next release (coming out in the next Luke> week) just to prove it. That isn't really the big deal here. As you point out, it is trivial to add something like this to a tool. (any tool) It is just a piece in a far larger puzzle. Luke> Once again, you haven't looked at Puppet, you've just assumed Luke> it doesn't have features you consider critical. I have looked at puppet a little bit, but the language design, quite frankly, turns me off quite a bit. You've admitted that you haven't taken a close look at bcfg2 in the past; I would assume that is still the case. >> So I guess one of the larger differences between the two models >> is that Bcfg2 is designed to support reconciliation from the >> ground up. You could probably much of the same functionality with >> Puppet, but I don't think that you could actually get all of the >> way there. And I am not sure that Puppet is really designed in a >> way that it would be useful to do so. Luke> Well, now you can be sure -- Puppet is designed with the same Luke> functionality in mind. Its later design was affected somewhat Luke> by your discussion of bcfg (1, at the time, I think), but one Luke> of the frustrations I've always had with cfengine is that you Luke> could not tightly control access to the system, so providing Luke> that control was always one of my primary goals. What do you mean by tightly control access to the system? All of this functionality is derived from bcfg2's validation model, which is more complicated than the "we validate all entries in the configuration" approach that you have described for Puppet. We leverage this for all sorts of things all over the system. When I look at puppet, I see something that looks like an amalgamation of bcfg and LCFG, with some cfengine bits as well, using a data model that is a lot finer granularity, like LCFG uses. You have done a ton of work to build an abstraction platform with very fine-grained objects. I presume this is why you have such a large codebase. These are not unreasonable decisions to make, but I don't agree that abstraction issues are the key problem facing administrators. If I understand you properly, your theory is that if you build an abstraction system, they will come. Please do tell me if any of this is incorrect. I witnessed enough conversations at LISA, previous configuration management workshops, and mailing list traffic about Puppet to have a halfway decent high-level view of its architecture. So, the problem that I do think is critical is the user model. We have spent a fair amount of time modeling this, and figuring out how users think about the system. We've actually spent a lot of time figuring out how to use the data yielded by our validation model to get increased efficiency or decreased frustration for users. Quite simply, it seems to me that you don't have a completely reversible configuration language, so it is not possible to build the same sort of reconciliation-based system using Puppet as the basis. Look, I have already implemented and field-tested a system that does this properly. I know what infrastructure it requires, and what architectural decisions preclude it. Using a fine-grain, LCFG-like model makes this _really_ difficult, if not impossible. You've closed this door, at least mostly, but you have opened up another. That is fine, let a thousand flowers bloom; we just aren't growing the same flowers here. These features sound trivial, but it makes the world (at least our world) function in a different way. It turns out that we spent a ton of time on a technically difficult feature, and users don't give a damn. The opposite is also true. Sometimes things that seem easy take a ton of fine-tuning before it really works. It also takes a large guinea-pig-style user population that (a) doesn't mind suboptimal solutions, and (b) doesn't mind being frequently interrogated to develop really useful solutions. It turns out that a reconciliation-based model is a lot better for groups that contain administrators that make manual changes. (and what group does not) I am not saying that this is necessarily the right model for everyone, but we've seen some pretty fantastic results out of the model, and i think it is a good next step forward for tools. In a nutshell, this is why I think that the research community is essential in this effort. You will likely come out of the whole Puppet experience with some interesting insights on the easy/hard, high/low, good/bad points of building a comprehensive portability layer across a lot of systems. I would love to hear what you have to say about that. Without listening to you, I would be doomed to make the same mistakes. These systems are subtle and complicated. Luke> Puppet actually has an internal transactional system, which at Luke> some point will allow recording and rolling back of system Luke> changes. I would have wanted this anyway, but my time at Luke> BladeLogic certainly convinced me that it was a good idea. I Luke> distinctly remember the time I spent nailing down the design Luke> so that the transaction *always* had tight control over what Luke> happened on the system. That sounds cool. We have an audit log, but haven't automated rollbacks of any sort. This is a really good idea, and is one place we haven't really focused yet. Luke> I'd apprecate you looking into what Puppet can do and how it Luke> actually works before assuming things like this about it. Luke> Yes, I've taken a different tack in terms of the focus, and a Luke> lot of the documentation is necessarily focused on writing the Luke> granular specification code rather than the association code, Luke> but that's because the association stuff is really easy and Luke> the granular stuff is actually pretty time-consuming, Luke> especially when done portably. I probably should have taken a closer look at the code, but unless any of my comments are incorrect above, I had a good enough idea to assess how hard it would be to implement reconciliation-style features like bcfg2 has. I would appreciate corrections; I certainly don't want to say incorrect things. I suppose that I have the same revulsion to ruby that you have to python. To each his own, i guess. Luke> I understand you wanting to think that Puppet is just Luke> cfengine++, with all of the same faults, but I state Luke> categorically that it is not. I learned a lot from cfengine, Luke> ISconf, a *lot* of my own code, BladeLogic, LCFG, bcfg2, Luke> SmartFrog, and quite a bit more. Please do not assume that I Luke> wrote this product based on some hacking with cfengine. I don't. As I said above, the inspiration from several of these tools is obvious. It is obvious that you have done a lot of thinking and hard work on puppet. My only comments were that I had the same style of negative reactions to puppet that i did to cfengine; some similarity, perhaps only cosmetic, seems to really stick in my craw. Consider this a personal failing. Luke> I'd really appreciate if the next person who wants to Luke> denigrate Puppet at least looked at it long enough to know if Luke> they were right or not. 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. Likewise, I would suggest that you take a little closer look at bcfg2 before claiming that it is equivalent, or even feature comparable to puppet. I find it quite frustrating when you do so. We are trying to accomplish two different things, and are only using vaguely similar infrastructure to do so. -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss