- From: Daniel DeLeo <
>
- To:
- Subject: [chef] Re: Empty run list after failed run (Windows)
- Date: Fri, 20 Feb 2015 14:42:45 -0800
On Friday, February 20, 2015 at 2:10 PM, Brian Begy wrote:
>
I’m using knife-rackspace to create servers. Whenever I experience an
>
error, the next time I run chef, my node’s run list is empty.
Chef avoids saving data until the end of the chef-client run because you
might rely on attributes you set some time during the run to be available for
searching. Because of the way the bootstrap process works (it puts some files
on disk for chef-client to read so it can create the node itself), the run
list just doesn’t get saved to the server.
You can work around this by running chef-client -j /etc/chef/first-boot.json
when you run chef-client the next time.
>
>
Is this desired behavior?
This is pretty annoying, and there are a few ways it can be fixed. On a
fundamental level the problem is that the node object mixes desired state
(instructions you give chef-client that tell it how to configure a node to
your liking) with last observed state (attributes from ohai and cookbooks
that are set based on what chef-client actually did the last time it ran).
I’m working on a feature called policyfiles that fixes a lot of this by
making a separate object on the server own the run list (there’s a lot more
to that, see here:
https://github.com/chef/chef-dk/blob/master/POLICYFILE_README.md ).
A more targeted fix would be for chef-client to check for
/etc/chef/first-boot.json and use it if it’s around, but then move it out of
the way on the first successful run. Overall, that’s not too hard to do, but
it would have to be implemented in a way that wouldn’t break anyone who had a
stale first-boot.json lying around (probably could be a config option to
enable this and then the bootstrap process could set this to enabled by
default).
Alternatively, the bootstrap process could create the node object ahead of
time with the desired run list already set. This gets a bit tricky with
search because if you configure your load balancer by searching for nodes
with a particular run list item, your load balancer might get configured to
treat an incomplete node as an upstream server. That could be mitigated by
using node tags or some other attribute to find upstreams, but it would be a
cookbook code change for many people, so that would have to be an opt-in
behavior at first.
>
Am I missing something here?
>
>
Thanks!
>
>
Brian
HTH,
--
Daniel DeLeo
Archive powered by MHonArc 2.6.16.