On Tue Aug 12 14:48:15 2014, Daniel DeLeo wrote:
On Tuesday, August 12, 2014 at 2:40 PM, Douglas Garstang wrote:
Tried that. Waited a couple of minutes, and the nothing returned by my knife search. Run chef-client, and the knife search command does return data for the node.
I think there was more options after the -z.
Either you’re misremembering or there was a lot more to it. The
-z option just runs chef in “local mode” where it starts a Chef Zero server bound to localhost and saves data to disk. The
-z option takes optional arguments to run specific recipes without changing the run_list so you have something along the lines of
chef-apply but with server features available.
You can use
node.save to force Chef to save the node object at any time, but beware that any attributes you set after calling
node.save won’t appear in the data, which can cause search to intermittently not find nodes. Also, depending on which flavor of Chef Server you use and how it’s tuned, there is some latency to when things get indexed. Eventually everything will get upgraded to Solr 4 which has in-memory commit for much lower latency, but I’m not sure what the release timeline is. I think Hosted Enterprise Chef is using Solr 4 now, not sure about the others.
Yeah, I think we’ve discussed creating a node object up front in the
bootstrapper so that the node will at least exist and have its run list
when chef-client tries to search (but even that would be subject to
sleeping for a period and hoping solr had indexed it by the time the
chef-client run needed to search).
You’re probably better off doing it yourself and putting a node.save in
your recipe and then retrying search until it shows up, or wrapping
search with your own API that will combine the local node with the
returned search results if the local node satisfies your search terms.