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


Chronological Thread 
  • From: Kevin Keane Subscription < >
  • To: < >
  • Subject: [chef] RE: Re: RE: Re: Re: Re: RE: Chef Search for Node Discovery.
  • Date: Sun, 14 Jun 2015 13:10:46 -0700

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

When I try "knife search node" without specifying any criteria, I get zero results. Which makes sense to me. Try "knife search node 'name:*'" or something like that.

And, yes, of course nodes persist on shutdown. That's by design. After all, chef has no knowledge whether you mean to permanently shut down a node, turning it off for a maintenance window, or simply rebooting it.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html


-----Original message-----
From: Douglas Garstang < >
Sent: Sunday 14th June 2015 12:33
To:
Subject: [chef] Re: RE: Re: Re: Re: RE: Chef Search for Node Discovery.

Kevin,

I was just doing a "knife search node" and throwing the results into a file, since I didn't know if my search criteria would yield a result anyway. Someone just suggested I put node.save and the start of my run list. I just tried that. It seems to help. I'll move forward with that approach for now as it's simple. But, now my script that adds the instance on boot has to also remove it on shutdown, or else I'll have dead nodes hanging around. The work never ends.... :-\

Doug.

On Sun, Jun 14, 2015 at 12:13 PM, Kevin Keane Subscription < " target="_blank" title="This external link will open in a new window"> > wrote:

What exact search command are you using? I also assume that the other new nodes are called test02 and test03?

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html


-----Original message-----
From: Douglas Garstang < " target="_blank" title="This external link will open in a new window"> >
Sent: Sunday 14th June 2015 11:58
To: " target="_blank" title="This external link will open in a new window">
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:

{
  "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:

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 < " title="This external link will open in a new window" 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




--



--


  • [chef] RE: Re: RE: Re: Re: Re: RE: Chef Search for Node Discovery., Kevin Keane Subscription, 06/14/2015

Archive powered by MHonArc 2.6.16.

§