On Thu, Apr 14, 2011 at 5:09 PM, AJ Christensen firstname.lastname@example.org 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
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 Jacob, Chief Product Officer
T: (206) 619-7151 E: email@example.com