> 1. By default, data about nodes isn’t available until after the chef client has run at least once.This is correct.> 2. Node.save at the start of the run list should fix this, but it does not.Are you running node.save inside of a ruby block or are you running it at compile time? I’m not familiar enough with the Chef Client to know whether one of those is the better option for you or not, but it might be worth printing out `node.to_json` to see exactly what is getting sent to the Chef Server.> 3. Putting a 60s/90s sleep before the knife search, which should allow solr to complete a re-index has no effect.Which version of the Chef Server are you running? Chef Server 12 ships with Solr 4 and is configured to make updates to the search index available for searching once per second as opposed to once per minute in Chef Server 11.> 5. Even if node.save did work, it won’t run on vagrant and throws an error.That error you posted seems to imply that the client had trouble reading /etc/chef/client.pem. This is strictly a client-side issue. Does this file exist? If so, what are the permissions on it? Did you run chef-client as root?
—
Stephen Delano - Engineering Lead, ChefOn Tue, Jun 16, 2015 at 12:58 PM, Douglas Garstang < " target="_blank"> > wrote:
Doug.4. Doing a dummy run of the chef-client and pointing it to a no-op recipe to get around (1) above requires passing the -r option which has the side effect of updating the run list on the chef server so that the next call to chef-client uses the dummy cookbook, not the cookbook this node was originally provisioned to use.3. Putting a 60s/90s sleep before the knife search, which should allow solr to complete a re-index has no effect.2. Node.save at the start of the run list should fix this, but it does not.So, let me summarise this sorry situation...1. By default, data about nodes isn't available until after the chef client has run at least once.5. Even if node.save did work, it won't run on vagrant and throws an error.Did someone intentionally design chef server to induce scraping eyes out with a rusty razor blade? I'm pretty fed up.On Tue, Jun 16, 2015 at 12:51 PM, Douglas Garstang < " target="_blank"> > wrote:Doug.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. :(--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, ChefOn Tue, Jun 16, 2015 at 11:50 AM, Douglas Garstang < " target="_blank"> > wrote:
DougHow can I make this reliable?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).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.Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627
--Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627
Archive powered by MHonArc 2.6.16.