# CHEF-13 - dry-run / no-op mode

**URL:** <https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316>\
**Category:** Chef Infra (archive)\
**Created:** [November 30, 2009, 10:28am UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316 "2009-11-30T10:28:13Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jon](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@jon](https://discourse.chef.io/u/jon)\
**Post date:** [November 30, 2009, 10:28am UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316/1 "2009-11-30T10:28:13Z")

</div>

Hi,

I had a great weekend getting Chef up and running on some lab kit,  
looking at it as an alternative to homegrown scripts and Puppet. It’s an  
impressive system so firstly thanks for writing and sharing it 🙂

I was wondering about the no-op stuff hinted at in CHEF-13. For me the  
ability to eyeball proposed changes on (a sample of) nodes is pretty  
important, both for avoiding silly mistakes whilst learning the ropes  
and as a checkpoint before rolling out scarily large changes.

If Chef has this ability I can’t find it, and if it doesn’t then I’m  
wondering if the problem is something a keen Rubyist could work on. Only  
48 hours I’m admittedly naive about Chef’s internals, it might be a hard  
one that needs serious attention from core developers rather than me  
blundering in!

Sorry if this is a FAQ or similar, I couldn’t find much mention of it  
other than the ticket.

Regards, jon.

[http://tickets.opscode.com/browse/CHEF-13](http://tickets.opscode.com/browse/CHEF-13)

---

<div class="post-metadata">

**Author:** ![Bryan\_McLellan](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_mclellan/32/81_2.png) [@Bryan\_McLellan](https://discourse.chef.io/u/Bryan_McLellan)\
**Post date:** [November 30, 2009, 10:34am UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316/2 "2009-11-30T10:34:24Z")

</div>

On Mon, Nov 30, 2009 at 2:28 AM, jon stuart [lists@zomo.co.uk](mailto:lists@zomo.co.uk) wrote:

> I was wondering about the no-op stuff hinted at in CHEF-13. For me the  
> ability to eyeball proposed changes on (a sample of) nodes is pretty  
> important, both for avoiding silly mistakes whilst learning the ropes  
> and as a checkpoint before rolling out scarily large changes.

It is not implemented yet. I believe the problem is that you would  
have to write support for it into every provider individually. In the  
interim, you would have to bail on all providers that didn't support  
it. Which while running in noop mode is probably fine because you  
weren't going to do anything anyway, it would take a concerted effort  
to get a full noop run working all the way through.

> Sorry if this is a FAQ or similar, I couldn't find much mention of it  
> other than the ticket.

No worries, that's what we're all here for.

Bryan

---

<div class="post-metadata">

**Author:** ![jon](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@jon](https://discourse.chef.io/u/jon)\
**Post date:** [November 30, 2009, 11:42am UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316/3 "2009-11-30T11:42:36Z")

</div>

Bryan McLellan wrote:

> On Mon, Nov 30, 2009 at 2:28 AM, jon stuart [lists@zomo.co.uk](mailto:lists@zomo.co.uk) wrote:
> 
> > I was wondering about the no-op stuff hinted at in CHEF-13. For me the  
> > ability to eyeball proposed changes on (a sample of) nodes is pretty  
> > important, both for avoiding silly mistakes whilst learning the ropes  
> > and as a checkpoint before rolling out scarily large changes.
> 
> It is not implemented yet. I believe the problem is that you would  
> have to write support for it into every provider individually. In the  
> interim, you would have to bail on all providers that didn't support  
> it. Which while running in noop mode is probably fine because you  
> weren't going to do anything anyway, it would take a concerted effort  
> to get a full noop run working all the way through.

Ah right, thanks for the clue-in. So definitely in the non-easy category!

I'll continue to play with Chef regardless, its strengths demand it 🙂

Regards, jon.

---

<div class="post-metadata">

**Author:** ![Bryan\_McLellan](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_mclellan/32/81_2.png) [@Bryan\_McLellan](https://discourse.chef.io/u/Bryan_McLellan)\
**Post date:** [November 30, 2009, 11:59am UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316/4 "2009-11-30T11:59:24Z")

</div>

On Mon, Nov 30, 2009 at 3:42 AM, jon stuart [lists@zomo.co.uk](mailto:lists@zomo.co.uk) wrote:

> Ah right, thanks for the clue-in. So definitely in the non-easy category!

Actually, I think it is easy, but will take a bit of time for someone.  
I think it'd be a great way for someone new to chef to get intimate  
with the code base.

Bryan

---

<div class="post-metadata">

**Author:** ![Kolbrich](https://avatars.discourse-cdn.com/v4/letter/k/8dc957/32.png) [@Kolbrich](https://discourse.chef.io/u/Kolbrich)\
**Post date:** [November 30, 2009, 12:41pm UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316/5 "2009-11-30T12:41:20Z")

</div>

I have been testing chef configuration on several virtual machines.  
Then you can actually test them and then tear them down and rebuild  
them from time to time.

-Kevin

On Nov 30, 2009, at 6:43 AM, jon stuart [lists@zomo.co.uk](mailto:lists@zomo.co.uk) wrote:

> Bryan McLellan wrote:
> 
> > On Mon, Nov 30, 2009 at 2:28 AM, jon stuart [lists@zomo.co.uk](mailto:lists@zomo.co.uk) wrote:
> > 
> > > I was wondering about the no-op stuff hinted at in CHEF-13. For me  
> > > the  
> > > ability to eyeball proposed changes on (a sample of) nodes is pretty  
> > > important, both for avoiding silly mistakes whilst learning the  
> > > ropes  
> > > and as a checkpoint before rolling out scarily large changes.
> > 
> > It is not implemented yet. I believe the problem is that you would  
> > have to write support for it into every provider individually. In the  
> > interim, you would have to bail on all providers that didn't support  
> > it. Which while running in noop mode is probably fine because you  
> > weren't going to do anything anyway, it would take a concerted effort  
> > to get a full noop run working all the way through.
> 
> Ah right, thanks for the clue-in. So definitely in the non-easy  
> category!
> 
> I'll continue to play with Chef regardless, its strengths demand it 🙂
> 
> Regards, jon.

---

<div class="post-metadata">

**Author:** ![Matthew\_King](https://avatars.discourse-cdn.com/v4/letter/m/c68b51/32.png) [@Matthew\_King](https://discourse.chef.io/u/Matthew_King)\
**Post date:** [November 30, 2009, 1:40pm UTC](https://discourse.chef.io/t/chef-13-dry-run-no-op-mode/1316/6 "2009-11-30T13:40:25Z")

</div>

Bryan McLellan [btm@loftninjas.org](mailto:btm@loftninjas.org) writes:

> On Mon, Nov 30, 2009 at 2:28 AM, jon stuart [lists@zomo.co.uk](mailto:lists@zomo.co.uk) wrote:
> 
> > I was wondering about the no-op stuff hinted at in CHEF-13. For me the  
> > ability to eyeball proposed changes on (a sample of) nodes is pretty  
> > important, both for avoiding silly mistakes whilst learning the ropes  
> > and as a checkpoint before rolling out scarily large changes.
> 
> It is not implemented yet. I believe the problem is that you would  
> have to write support for it into every provider individually. In the  
> interim, you would have to bail on all providers that didn't support

Providers that don't provide no-op functionality need only barf when  
it's asked for (controlled by the code which calls the provider)[0]. If  
chef is running in op mode, legacy (as they would then become) providers  
can simply run as specified, optionally emitting a warning, because  
overall there'd be no change from the status quo.

Matthew

[0] It should be noted that I've never looked at the chef code so I may  
well be talking out of my backside. User discretion advised.

--  
I must take issue with the term "a mere child", for it has been my  
invariable experience that the company of a mere child is infinitely  
preferable to that of a mere adult.  
-- Fran Lebowitz