>>>>> "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

Reply via email to