Chef

I want to bump this as I think it's pretty much essential for a production cluster to be able to test run config's first.

An un-named hosting company I used to work for used to have an excellent no-op mode on the cli tools for manipulating cluster members. It would print lots of debug text and list exactly what was being written to templates.

I think that rather than a noop option it should be a standalone chef-test script that takes the following options:

-j a json representation such as that would be obtained from ohai, which is fed into chef as the fake chef-client

-r a run list representing everything to run against this fake client

I would then to be able to maintain a local copy of various json files describing each of my different types of cluster members that I could then run cookbooks against. It would also be a great way to verify cookbooks before deploying to the cluster, a must for production machines.

Linking a discussion about this from late last year:

<http://lists.opscode.com/sympa/arc/chef/2009-11/msg00020.html>

I concur, I can't make a case for Chef at two largish client sites because of the perceived risk of a system that only informs about changes after the event.

Feebly I've got nowhere in implementing it myself, though!

I've been thinking of writing a rspec harness for chef that would allow for writing specs against your recipes. The techniques used for this ticket could also be used to for the testing harness.

Is there any progress on this ticket? Is it even on the roadmap?

I addition to providing a way for the overly paranoid to ease their way into the Chef way, this is also a critical feature for the unavoidable case where you need to bring something under Chef control that wasn't built that way from scratch. Of course you don't want to do this if you can avoid it, but sometimes you have no choice. In this case, you really need to see what's going to happen before you actually make changes. I know Opscode is pushing to sell Chef to cloud users where this matters less because everything should be rebuildable, but lots of users are running Chef in the datacenter or in a hybrid model where some things aren't that way. Seems like this would also address similar requests such as CHEF-2064

Anyone started a fork for this + made any progress that we can close out?

My use case is to allow refactoring of recipes to quickly test that the refactoring and the original did the same thing.

My solution was to monkey patch all of the providers that I use in my recipes. In the patch, I overwrite the action_create method (or whatever method is responsible for carrying out the action), and instead of executing the action, it will just either output what action will be executed, or do it in a staging area. You can read it more here:

http://www.vim-fu.com/patching-chef-to-support-dry-run-mode-by-darren-dao/

There are some bugs with the code in that post, but I'm too lazy to update it.

Yes - we have a couple of different approaches working in branches, and are talking about which one we're going to actually adopt.

@Darren - I did see that earlier and was going to ask if it was still working against chef 0.10

@Adam - that's great, thanks for the update

This email from Adam [1] was part of the aforementioned email thread, but the mail archive doesn't show it correctly. It is an important read to understand the complexities and trade-offs of making a complete and fully useful noop mode.

[1] http://lists.opscode.com/sympa/arc/chef/2009-11/msg00026.html

The thread was split across a month boundary, which further confused the archiver. My response, and Adam's to that, can be found here: <http://lists.opscode.com/sympa/arc/chef/2009-12/msg00002.html>

I suppose that we need this feature. It's one of advantages of Puppet.

Another --noop (--dry-run) thread: http://lists.opscode.com/sympa/arc/chef/2012-02/msg00237.html

Being able to run Chef to see what would be done without doing it is an essential aspect of a configuration system. The --noop recommendation covers this pretty well. It's especially useful for:

• runs from monitoring system modules
• checking to see if a systems has been manually modified without obliterating the changes outright
• testing new recipes
• testing an old recipe on a new architecture of system

This list is not exhaustive. My support of this feature has nothing to do with puppet, which I disliked, but rather because any system that lacks it is uninstallable in my environment.

Some other aspects of --noop that deserve attention:

• specifying which subsystems to run to reduce overall time (monitors, testing) - chef may have this already.
• concise output of which are already correct, or which need a non-noop pass in order to correct.
• ideally the main normal chef output would have { correct, fixed, broken, inapplicable } in a concise form for runs

It would be very reassuring to be able to get single line for each recipe/cookbook, listing status as described, and with options to suppress any of them (my home-rolled system has this, so I'm probably just projecting here). Conversely, outputting a list of ruby/Chef API calls that would be applied to a system would be great for debugging, so don't let my favoring of one-line-per-subsystem be considered a constraint

I'd like to add a big +1 to this. This feature is pretty critical for our potential uses of chef. Having noop mode would allow us to consistently monitor whether or not the machine needs to be updated without constantly taking it offline to do so.

Behold the most ancient of all zombie tickets!

A good stopgap would be to identify the current state of all resources. Essentially just run a compile phase then each provider's load_resource and hand over the lot to a friendly chef_handler.

Must read: http://lists.opscode.com/sympa/arc/chef/2012-02/msg00257.html

In the previous thread, I show a real life example of an existing --dry-run implementation, examining the compromises that prevent it from being completely truthful about what it "would" do.

New whyrun thread: http://lists.opscode.com/sympa/arc/chef-dev/2012-04/msg00037.html

There's some development happening here wherein we're engineering what we believe to be an intelligent approach to noop/dryrun/whyrun.