- From: Dan DeMaggio <
>
- To:
- Subject: [chef] Re: Re: Re: dry-run / no-op mode
- Date: Thu, 3 Dec 2009 11:21:56 -0500
On Thu, Dec 3, 2009 at 4:52 AM, Adam Jacob
<
>
wrote:
>
Anyone else?
Yes, I'd say a dry-run mode would be helpful. I think there's two
ways to look at a dry-run mode:
1) it will tell you what will happen
2) it will tell you what it wants to change
I think we all agree that #1 is a fantasy -- it can't predict 100%
what will happen. The analogy to Make is a good one. Dry run isn't
going to be very useful if you're running Chef for the first time ever
-- there's just too much going on. (But it might be useful to say
"chef --dry-run | grep Package" to see which packages it would install
as a sanity check).
But #2 is very useful. Much of the time we make small changes and just
want to make sure nothing is screwed up ("oh, no, it pulled in the
wrong recipe and now my DNS server running MySQL"). I think of
Dry-run as more of a sanity check to see what's changed since the last
run.
Of course, nothing is going to be 100% accurate (or even safe. See
"ruby -c" with BEGIN blocks). I think we can set user's expectations
with just a paragraph or two, and it will be a useful tool.
Down the road it would be neat to put in warnings during dry run, such
as: "warning package doesn't exist in repo" or "warning file doesn't
exist when trying to set owner". That way the user gets hints on what
would fail, but dry-run can still assume nothing will fail. Some of
the warnings would be invalid (i.e. trying to modify http.conf after
installing apache during a dry run), and some would be valid (i.e.
trying to modify "/etc/hsots").
-=Dan=-
Archive powered by MHonArc 2.6.16.