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