[chef] Re: Why does chef have a two-pass execution flow?

[Dan Razzell < >]

I guess the why makes more sense intuitively if you have some background in configuration management.

The basic idea of configuration management is to specify how a given class of system should be configured, where "configured" means being in a measurable state.

Some mechanism separate from this specification then comes along, compares a given system to its specification, and applies changes intended bring the system into line with its specification.  In Chef this activity is called "convergence".

Specifications are fundamentally declarative.  They represent policy, not mechanism.  They're supposed to be entirely agnostic to how the convergence takes place.

What you're proposing is to treat specifications as if they were procedural, not declarative.  That's fine, but then you have lost the point of configuration management.   You're just programming again.

Mark Burgess has done some interesting work in this area.  Look for his name against "computer immunology".

You're not alone in finding yourself tempted with Chef to add "just a bit" of procedural content to your specification.  I know the feeling well.  It starts out innocently at first.  You think, well, I have to define a group of similar resources.  I'll just iterate over them neatly like this.  Then you realize that one of the resources is really a bit of a special case.  So you thrown in a conditional.  A bit of this here and that there... at some point, you forget that it's a specification.  It's starting to look more like an algorithm.  And now you're frustrated by this whole compile/runtime thing.  It's getting in the way of your algorithm!

No, actually.  What's happened is, you've let scope creep break your specification.  That's all, really.

On 13-01-28 06:16 PM, Ian MacLeod wrote:

" type="cite"> Sorry if this is (most likely) a repost; I wasn't able to find any dupes in the list archive, though :(

Chef executes recipes with a two pass model: First it compiles each resource/provider by walking through the run list.  Then it converges each of the compiled resource/providers to get the host to the desired state.

While I (finally) understand how it works; I don't understand the why.  It seems like there are quite a few pitfalls w/ this model:

* It is very easy to execute tasks out of order by accidentally defining work outside of a resource (forgetting to use execute/ruby_block providers, dropping to lower level Ruby, etc)

* LWRPs that declare inline resources have a confusingly different execution order (their actions occur in the convergence phase, but any resources they declare get run after the current provider)

* It is not very obvious to newcomers; they seem to expect that recipes are executed immediately.

What are the benefits of this two pass architecture?  Why was Chef built this way?  (I'm not finding obvious docs on it)

Thanks,

-Ian