Add Client to Chef Server Immediately?

Chef Infra (archive)
1

Anyone,

I remember seeing a trick recently, where a certain invocation of the
chef-client (with -z I believe) would allow a new node to report the data
it normally sends to a chef server at the end of it’s run. This would allow
cookbooks that use chef search to work the first time. Anyone know what it
is?

Douglas.

2

On Tue Aug 12 14:31:00 2014, Douglas Garstang wrote:

Anyone,

I remember seeing a trick recently, where a certain invocation of the
chef-client (with -z I believe) would allow a new node to report the
data it normally sends to a chef server at the end of it's run. This
would allow cookbooks that use chef search to work the first time.
Anyone know what it is?

Douglas.

chef-client -z spins up a chef-zero server and points the client at it:

3

Lamont,

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.

Doug.

On Tue, Aug 12, 2014 at 2:37 PM, Lamont Granquist lamont@opscode.com
wrote:

On Tue Aug 12 14:31:00 2014, Douglas Garstang wrote:

Anyone,

I remember seeing a trick recently, where a certain invocation of the
chef-client (with -z I believe) would allow a new node to report the
data it normally sends to a chef server at the end of it's run. This
would allow cookbooks that use chef search to work the first time.
Anyone know what it is?

Douglas.

chef-client -z spins up a chef-zero server and points the client at it:

chef_zero_thirty_seconds.md · GitHub

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

4

On Tuesday, August 12, 2014 at 2:40 PM, Douglas Garstang wrote:

Lamont,

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.

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

--
Daniel DeLeo

5

On Tue Aug 12 14:48:15 2014, Daniel DeLeo wrote:

On Tuesday, August 12, 2014 at 2:40 PM, Douglas Garstang wrote:

Lamont,

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.

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

--
Daniel DeLeo

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.

6

Daniel,

Caveats aside, where would the node.save go? Would it go in the recipe
somewhere very early in the run list? I think the hack I saw had this run
on the client side with chef-client.

Doug.

On Tue, Aug 12, 2014 at 2:48 PM, Daniel DeLeo dan@kallistec.com wrote:

On Tuesday, August 12, 2014 at 2:40 PM, Douglas Garstang wrote:

Lamont,

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.

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

--
Daniel DeLeo

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

7

On Tuesday, August 12, 2014 at 3:38 PM, Douglas Garstang wrote:

Daniel,

Caveats aside, where would the node.save go? Would it go in the recipe somewhere very early in the run list? I think the hack I saw had this run on the client side with chef-client.

Doug.
Yeah, you can put it in a recipe, probably at the top-level (i.e., not in a ruby_block resource) so it’ll run during the compile phase. If you’re using a Chef Server with the older Solr (most likely if you’re not on Hosted Enterprise Chef) then the next commit should happen within 60 seconds (assuming you haven’t changed the default tuning). So you have to either sleep 60 or poll search until the node can find itself. If you opt for polling, make sure you have sufficient wait time in between checks or else you can kill the server performance in some situations (e.g., you bring up a new test environment with a bunch of brand new nodes and they’re all hammering the server).

--
Daniel DeLeo

8

On Tue Aug 12 15:54:56 2014, Daniel DeLeo wrote:

On Tuesday, August 12, 2014 at 3:38 PM, Douglas Garstang wrote:

Daniel,

Caveats aside, where would the node.save go? Would it go in the recipe somewhere very early in the run list? I think the hack I saw had this run on the client side with chef-client.

Doug.
Yeah, you can put it in a recipe, probably at the top-level (i.e., not in a ruby_block resource) so it’ll run during the compile phase. If you’re using a Chef Server with the older Solr (most likely if you’re not on Hosted Enterprise Chef) then the next commit should happen within 60 seconds (assuming you haven’t changed the default tuning). So you have to either sleep 60 or poll search until the node can find itself. If you opt for polling, make sure you have sufficient wait time in between checks or else you can kill the server performance in some situations (e.g., you bring up a new test environment with a bunch of brand new nodes and they’re all hammering the server).

--
Daniel DeLeo

Something along these lines...

hack to update run list in the database so we can search and find

ourselves later
node.save

wordpress_nodes = nil
tries = 50
loop do
Chef::Log.info("Searching for wordpress nodes...")
wordpress_nodes = search(:node, "role:wordpress AND
chef_environment:#{node.chef_environment}")
break unless wordpress_nodes.empty?
break unless ( tries -= 1 ) < 0
Chef::Log.info("Found zero nodes in #{node.chef_environment}
environment, retrying (left: #{tries})")
sleep 2
end

Of course the obvious bug there is that if you've already got nodes in
your environment it'll find those and you wont find yourself because of
the race between the node.save and the results showing up in solr. You
could instead loop until you got results containing yourself or
something if you always expect to get yourself to show up. Of course
then its probably better to just combine the node data you have with
the search results you get back and avoid worrying about the round trip
to solr just to get your own node data back.