[chef] Re: Re: RE: Chef Search for Node Discovery.


Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Subject: [chef] Re: Re: RE: Chef Search for Node Discovery.
  • Date: Sun, 14 Jun 2015 11:48:05 -0700

On Saturday, June 13, 2015 at 2:03 PM, Douglas Garstang wrote:
> Kevin,
>  
> My boot process runs a script that calls a knife node add, to add the node 
> to chef. Since it's been added to chef, it should be discoverable. However, 
> it's not discoverable until the client has run at least once. That seems 
> more like an architectural problem with chef, rather than a fundamental 
> flaw in the universe. :)

As described elsewhere in the thread, the amount of time it takes for an 
object to hit the search index depends on your configuration and whether or 
not you’re on Chef Server 12 (which upgrades to Solr 4, which has a “soft 
commit” feature, reducing indexing time to 1s from default of 60s).

What you’re probably seeing is that chef-client sets some data about its last 
run into the “automatic” attributes section (where ohai data lives). If your 
search query queries on these values, you won’t see it until chef-client 
runs. If you search for things like run list items, node names, etc., you’ll 
see them when the node is created (after the next Solr commit).

As for whether it’s an architectural issue with chef, sort of. It’s 
definitely a problem that the node object in Chef represents both 
desired/aspirational state and last observed state. On the other hand, it’s 
important that you be able to search for nodes based on one or that other of 
these. For example, you probably don’t want to add an application server into 
the load balancer rotation or begin monitoring it as a production system 
before the application is running. In other cases you definitely do want to 
find all systems, even if they’re not fully configured yet.

--  
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§