[[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] CHEF-2224


Chronological Thread 
  • From: AJ Christensen < >
  • To: Daniel DeLeo < >
  • Cc: Adam Jacob < >, , Chef Dev < >
  • Subject: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] CHEF-2224
  • Date: Fri, 15 Apr 2011 10:09:44 +1200

Yo,

On 15 April 2011 09:55, Daniel DeLeo 
< >
 wrote:
> 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.

We've had failed first-run (but attributes-saved) nodes show up in
monitoring (via search), so I'm -1 on this being a bad behavior
change; it certainly is a change of behavior, but with some testing,
I'd totally support it.

I think this could be a regression too, cause I seem to recall a time
where the attributes weren't saved to the node prior to the
application of the resource collection.

The fewer decision points diagnosing node-bootstrap-failure rings true.

Regards,

AJ

> 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: 
> 
>
>



Archive powered by MHonArc 2.6.16.

§