General discussion about Chef

[chef] Re: Re: Re: Re: Re: Chef Search Again


Chronological Thread 
  • From: Dennis Lovely < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Chef Search Again
  • Date: Wed, 17 Jun 2015 15:19:19 -0700
For us, we define our zookeeper ensemble as a hash, at our environment layer.  I know, it's not chef-search and you'd like to use it, but I consider ZK to be an extremely mission-critical piece, and I like to minimize the elasticness/reconfiguration of him as much as possible, just to err on the side of caution as it can be an extremely touchy beast.  All I need is a service outage triggered by a bombed chef-search, which triggered a reconfigure/restart of my ZK ensemble, and either: left me in a completely broken state, or potentially a split-brain scenario at 0300.  I feel more comfortable using chef-search in places where it might be ok I missed one single node, it's not going to create a full on outage for me, and that node will be picked up on the next chef-client run.  We get mixed delays after a node has converged of when Solr will have its indexes updated, and properly returning me the results of the updated node attributes.  Solr4 appears to be a great improvement to these delays.  +1 to an upgrade to Chef12/Hosted chef if this is the primary cause of your frustrations.  I love chef search, but I understand this limitation though, and instead architect my solutions to deal with these types of limits.

Alternatively, we've reduced the role ZK plays in our org, by letting ZK drive our application configurations, and moved service discovery to Consul.  This has been a really great win for us in terms of ease of discovery, and greatly smoothed out the elastic scaling up/down of our applications with no human intervention, and we can still use it in unison with Zookeeper.  I'm sorry you're feeling frustrated, but if you're experiencing frustrations with chef-search just to get Zookeeper ensemble setup, you have a long road to travel of debugging Zookeeper in failure scenarios, they will be much more frustrating than chef-search.  Just my .02

HTH,

-Dennis

On Wed, Jun 17, 2015 at 7:35 AM, Nathen Harvey < " target="_blank"> > wrote:
Douglas,

Your message (http://lists.opscode.com/sympa/arc/chef/2015-06/msg00189.html) includes language that is not considerate, respectful, or professional.

"Did someone intentionally design chef server to induce scraping eyes out with a rusty razor blade?" goes beyond describing your personal frustrations.  Clearly, you are frustrated and are having difficulty getting Chef to behave the way you'd like.

Our Community Guidelines require that you:

"Be careful in the words that you choose. Be kind to others. Do not insult or put down others."

and

* Be considerate.
* Be respectful.
* Be professional.
* Be careful in the words that you choose.

Eventually, your questions to the list will be ignored unless this behavior improves.  Additionally, continuing to post messages that are not in keeping with our community guidelines will lead to corrective action which will likely mean banning you from the community mailing list.  I don't really think anyone wants that.

I would welcome a live discussion via phone or video chat to answer any additional questions you have.  Please let me know what time would work best for you.

Thank you,
Nathen Harvey
Community Director, Chef

On Tue, Jun 16, 2015 at 6:41 PM, Douglas Garstang < " target="_blank"> > wrote:
Charles,

Your response viewed. After viewing the community guidelines, I see nothing there about using colorful language to explain a personal frustrating situation being against the rules. I do however see obvious things like personal threats against others, sexual harassment etc. Having said this, I realise I risk being removed for speaking my mind. If that's what eventuates, then let it stand as a matter of public record that I politefully disagree with your assesment.

Perhaps the community guidelines need to be updated to be more restrictive in nature?

Douglas.

On Tue, Jun 16, 2015 at 3:34 PM, Charles Johnson < " target="_blank"> > wrote:

Doug,

This is another reminder that the Chef community guidelines apply to all posts in this list, and that “be respectful” is part of those guidelines. Thoughtful, passionate human beings work hard on the Chef server. If you need a refresher, the guidelines are available for review here: https://docs.chef.io/community_guidelines.html . I strongly suggest you familiarize yourself with these guidelines as quickly as possible, and adhere to them strictly in the future.

While it is clear that you are fed up, and your frustration is completely understandable, saying things like “this sorry situation" and "scraping eyes out with a rusty razor blade” shuts down conversation instead of inviting response. It’s possible to be open and critical when sharing your frustrations around the functionality of the Chef server, without being dismissive of the work that has gone and continues to go into creating it.

This is not the first time someone has said something to you about your rhetoric on this list. Unless you are able to show that you can understand the difference between honesty and candor, it will be the last.

Thanks,
    --Charles

On June 16, 2015 at 12:59:12 PM, Douglas Garstang ( " target="_blank"> ) wrote:

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.
2. Node.save at the start of the run list should fix this, but it does not.
3. Putting a 60s/90s sleep before the knife search, which should allow solr to complete a re-index has no effect.
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.
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.

Doug.

On Tue, Jun 16, 2015 at 12:51 PM, Douglas Garstang < " target="_blank"> > wrote:
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.

§