Avoid using recommends "monit" in metadata.rb

[mahmoudimus]

Recommending monit, when using Berkshelf, will upload an undesired version of monit to the chef server. While this is being addressed by berkshelf/berkshelf#895, we should not depend on the recommends keyword.

[karmi]

Hi, sorry for not getting to you sooner.

I always understood Chef's recommends as a "soft" dependency declaration, and liked it.

(...) will upload an undesired version of monit to the chef server (...)

Can you be more specific what "undesired" here means? What is uploaded and what do you expect? How do you declare dependency on monit cookbook? Since the Berkshelf#895 has been since merged, do you still experience the issue?

[sethvargo]

I would highly suggest using binary dependencies - it's either a dep, or it's not.

[karmi]

@sethvargo That's quite problematic in this specific use case. There are multiple Monit cookbooks, with varying functionality and features. So the cookbook won't specify a "binary" dependency, because it leaves the decision about which Monit cookbook to use to the user.

[sethvargo]

That's a documentation issue though, not a dependency issue. Your cookbook is designed to work with one or more of those monit cookbooks, right? So you document that, then depend on monit.

[mahmoudimus]

I agree with @sethvargo -- although I am agreeing because I think the elasticsearch cookbook needs to be explicit about what version of monit it supports if it's required.

[karmi]

And here's where our approach differs, Seth. I document the situation like this in the README:

If you include the elasticsearch::monit recipe, it will create a configuration file for Monit, which will check whether Elasticsearch is running, reachable by HTTP and the cluster is in the "green" state. (Assumed you have included a compatible "monit" cookbook in your run list first.)

Based on long years of fighting dependency hell as an end-user in Ruby, in pre- and post- Bundler years, the last thing I want to do is to force that on them. So, if you want to use the elasticsearch::monit recipe, make sure you pick and use a Monit cookbook. Maybe you don't want to use the Monit integration at all -- then the dependency would be totally useless..

It's exactly the same issue with Java, by the way, which is arguably much more central to Elasticsearch usage:

It requires a working Java installation on the target node; add your preferred java cookbook to the node run_list.

Given how much I struggled with the Opscode Java cookbook over the years, the last thing I want to do to my end users is forcing them to use it. I can imagine many people writing their own lightweight Java cookbooks and perfectly satisfiying Elasticsearch requirements in that way.

[karmi]

@mahmoudimus No, the cookbook won't make that decision for you. Pick up a Monit cookbook you consider "good" (to quote you: “I am currently using https://github.com/phlipper/chef-monit which is a much superior cookbook for monit.”) and use it. The contract it has to provide to the Elasticsearch cookbook is quite minimal.

[mahmoudimus]

@karmi fair enough :)

[sethvargo]

@karmi - you mean like this: https://github.com/opscode-cookbooks/jenkins#java 😄

[sethvargo]

And: https://github.com/opscode-cookbooks/jenkins/blob/master/recipes/java.rb

[karmi]

@sethvargo Yeah, exactly like that.