
Why “Why-Run” Mode in Chef Is Considered Harmful - kiyanwang
https://blog.chef.io/2018/03/14/why-why-run-mode-is-considered-harmful/
======
core-questions
Why-run still has a ton of value.

One of the fastest ways to develop a new wrapper cookbook that assembles
together a bunch of community cookbooks and custom glue is to rapidly iterate
from within a machine.

You may want to stop me and say "but what about test kitchen?" \- and yeah,
it's very useful, but there are a lot of things that are more difficult or
time consuming to mock out in kitchen than one might like, e.g. interfacing
with services like certificate and credential repositories, registering with
other network services, etc. that you sometimes need to turn around in short
order.

So, bang out a cookbook with the basics and get it onto the chef server, run
the initial version on a host, and then edit the cached version on a host
using the --skip-cookbook-sync parameter to the chef client to run the local
copy. Doing this in why-run mode gives you the fastest iteration times
possible in a production-like environment. For small changes needed ASAP to
production, it's similarly the quickest path to something that will converge.
Especially since you're generally going to be running your test machine on
real hardware, instead of your over-taxed workstation...

Of course, when this is all done with, you need to sync your work back to your
cookbook repository and let it run through the proper CI/CD workflows, update
compliance tests if you have them, etc. but the time-to-deploy on production
is lower than any other way I've tried.

Dirty practice? Sure, maybe, but honestly there's so much posting on HN about
overly-idealized practices that sound great on paper but just aren't the kind
of thing overworked DevOps people have time for. Figuring out how to use
shortcuts is often the name of the game.

