On Thursday, April 14, 2011 at 10:16 AM, Adam Jacob wrote:
I just filed a blocker against 0.10 - the issue is that we no longer
save the node after the node object is created and the attribute files
are applied, but before the application of the resource collection.
This causes a pretty major behavior change - namely that you can no
longer easily inspect what attributes were applied to a node if the
first run fails, and if it fails during a bootstrap, you'll need to
pass -j /etc/chef/first-boot.json when you re-try (neither of which
you had to do with the 0.9 behavior).
But is it a *bad* behavior change?
For example, if you got the server URL wrong or had a random error while registering in 0.9 and lower, you never would have created the client or node, and therefore you'd have to run with -j again. The new behavior has fewer decision points--if the first run fails, you re-run with -j for all cases.
As for inspecting the attributes on a node after a failed run, I'm not sure what the value is here, where by "I'm not sure," I mean, I actually don't know. I've certainly never debugged a failed chef run this way. My gut feeling is that the state during the Chef run could be quite different from the initial save state, so you're better off checking the logs.
--
Dan DeLeo
Adam
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E:
">