[chef] Re: Re: Chef Search Again


Chronological Thread 
  • From: Douglas Garstang < >
  • To:
  • Subject: [chef] Re: Re: Chef Search Again
  • Date: Tue, 16 Jun 2015 12:51:14 -0700

Stephen,

Well, I just tried using chef-client -r dummy and that worked. However, that permanently replaces the run list on the chef server. If I now run chef-client, hoping to use the zookeeper cookbook formerly associated with the node, it's been replaced by the dummy one. I am so frustrated. :(

Doug.

On Tue, Jun 16, 2015 at 12:38 PM, Stephen Delano < " target="_blank"> > wrote:
> Sigh. I guess all I need is an empty cookbook that does nothing as node.save seems to have no effect anyway. All I need is a dummy chef client run.

How are you running this “dummy” chef-client run? If you change the run-list to remove the role role-zookeeper, your node will be persisted without this role and without the attributes associated with it. You’ll have a period of time where the roles attribute of the node does NOT contain what you’re looking for and searches will fail.


Stephen Delano - Engineering Lead, Chef


On Tue, Jun 16, 2015 at 11:50 AM, Douglas Garstang < " target="_blank"> > wrote:

The battle continues with chef search. I'm trying to use chef search to discover zookeeper nodes. The very first thing in my run list is node.save, which seems to cause the Chef server to immediately have access to the data I need, the role and the environment.

I just did a test, where one window had the result of "knife search node "chef_environment:dev AND roles:role-zookeeper". I could see that the data was populated immediately after the call to node.save. A few minutes later, when the recipe did it's search, no nodes were found, as evidenced from an empty log() statement in the recipe.

I've run the test a few times, and basically, the result are unreliable. On my latest test, two of the nodes discovered all three nodes, and one of the nodes discovered only one node (not itself btw).

How can I make this reliable?

Doug





--



Archive powered by MHonArc 2.6.16.

§