[chef] New user feedback and questions

[Brian Candler < >]

Hello,

I've been dabbling a bit with Chef, and I thought I would give a bit of
new-user feedback, in case you're interested :-)

(1) Something which confused me at first was the use of code blocks. In Ruby
these are usually callbacks to be executed zero or more times at some point
in the future (look at how Rake uses code blocks, for example).

But in Chef, it took me a while to realise that these are just executed
immediately as syntactic sugar for setting parameters. Take this example:

    service "apache" do
      action :enable
    end

    directory "/tmp/something" do
      recursive true
      action :delete
    end

It becomes much clearer (to me) if I translate this mentally to:

    service "apache", :action => :enable

    directory "/tmp/something",
      :recursive => true,
      :action => :delete

Now I see these as just a series of actions with parameters which are
executed one after the other, not tasks to be deferred. Therefore the issues
about ordering of actions vanish: if you want action A to be executed before
action B, you just write A before B :-)

<aside>
The second syntax I've shown above doesn't work right now, but perhaps
it could if the optional resource parameters 'collection' and 'node' were
made into hash options, i.e.

  directory "/tmp/foo", :collection=>xxx, :node=>yyy
</aside>

It's now clear to me (but wasn't at first) that there are no dependencies
apart from those which you set up with notifies/subscribes. For example: if
you define a task using 'execute', it will be run *every* time your recipe
is run, unless you set up a precondition like 'creates' or 'only_if'

I also found the concept of 'resource' a bit unclear at first. For example,
I may want to create a file using a script. But in that case, the 'resource'
is not a 'file' (the thing I want), it is an 'execute' (the way to create
it).

(2) Based on the above, I think there's a gap in the documentation between
installing/getting started (which installs your first cookbook without
really understanding it) and the detail of the individual components. But
maybe I was just being dumb.

I found the detailed documentation on resources/providers etc was fine, and
in any case it's easy enough to dig into the code once you get down to that
level.

I found another gap at
http://wiki.opscode.com/display/chef/Anatomy+of+a+Chef+Run
where it talks about "saving the state of a node". What exactly is saved?
For example, does every 'file' resource keep a backup of the given file?
Or is it just a dump of the node state from Ohai?

(Right now I'm just using chef solo rather than a server)

(3) In the environment where I work, the most likely need for chef is in
distributing config files [*].

So I'm looking as to ways we can make this as safe and simple as possible
for the sysadmins to use.

Have you any pointers to best practices on *testing* new recipes? I don't
really want to set up a whole dev/test environment just for developing and
testing each recipe change - it would be too cumbersome. But equally I don't
want invalid recipes being pushed out, or worse, ones which destroy data.

One possibility would be to distribute new versions of cookbooks to
machines, but only activate them in a dry-run way (like make -n). Only once
the expected actions are checked would I then enable the new cookbook to be
run live.

If this sort of functionality already exists, I'd be very happy to receive a
pointer to it. Otherwise, how are other people handling this?

Anyway, that's about it. This looks like a cool framework for machine
management, so thanks for releasing it!

Regards,

Brian.

[*] This is because most of the other functions are handled directly or
indirectly by the existing package manager. RH Satellite Server gets the
right packages installed on the boxes, and the packages themselves have
post-install scripts which create uids/gids and data directories with the
correct permissions and ownership. I don't want or need to duplicate this
logic in chef recipes.

However I can also see a need for a resource to fetch a particular svn/git
tag of source code, compile it, and install it. This would make it much
easier to deploy a head or near-head version of a rapidly developing
application such as CouchDB, without having to keep re-packaging it.