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

When you create the node object you will actually need to put all the useful information required that you would like to be able to search. Alternative approach might be to call node.save at the start of your first recipe. ‎I believe that would save all your role/environment attributes right away to the server (searchable after the Solr indexes). 

‎

From: Douglas Garstang‎

Sent: Sunday, June 14, 2015 2:58 PM

To:

Reply To:

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

Daniel,

I created three new nodes with the "knife node create" command, like this, for each:

{

  "name": "test01.dev.slicetest.com",

  "chef_environment": "dev",

  "json_class": "Chef::Node",

  "automatic": {

  },

  "normal": {

  },

  "chef_type": "node",

  "default": {

  },

  "override": {

  },

  "run_list": [

    "role[zookeeper]"

  ]

}

I've been doing a knife search repeatedly over the past 15 minutes, and all I get each time for the nodes is this:

Node Name:   test01.dev.slicetest.com

Environment: dev

FQDN:

IP:

Run List:    role[zookeeper]

Roles:

Recipes:

Platform:

Tags:

How long should I need to wait? The chef_environment is immediately populated. Why not the role? That comes from the run list and should be available immediately, just like the chef_environment. I need _at least_ the environment and the role to be able to do a useful search.

It does not take an instance 15 minutes to boot. Therefore, by the time the client runs, the data won't be available. Can I reduce the solr refresh frequency down to a useful value?

Douglas.

On Sun, Jun 14, 2015 at 11:48 AM, Daniel DeLeo < " target="_blank"> > wrote:

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

--

Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627