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


Chronological Thread 
  • From: Adam Jacob < >
  • To: AJ Christensen < >
  • Cc: Daniel DeLeo < >, , Chef Dev < >
  • Subject: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] CHEF-2224
  • Date: Thu, 14 Apr 2011 17:17:35 -0500

On Thu, Apr 14, 2011 at 5:09 PM, AJ Christensen 
< >
 wrote:
> 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 would argue this is exactly what you want - those nodes in fact
should be triggering alarms - the services they were supposed to be
running (given that your intent at bootstrap time was to have a
working system with that run list, not a non-existent one) - and they
now fail. You don't want the situation where the now-stranded systems
are not included in your monitoring because of a failed bootstrap, do
you?

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

It is a regression - there was a time when we didn't do this, and we
put this behavior in specifically for cases like the above.

In addition, this is a common early work pattern - you're tweaking
recipes, you're testing, and then you're building new systems from
scratch. The change away from storing the data early makes that loop
less intuitive (I've had 3 different people today comment on it.)

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

I feel like this is a red herring - if it brings you joy to include -j
/etc/chef/first-boot.json every time, go for it. :)

Adam

-- 
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: 




Archive powered by MHonArc 2.6.16.

§