Factor out Exhibitor

[jakedavis]

This PR is a massive change to accommodate the new [Exhibitor cookbook](). It will be a full version bump to 2.0.0, but is now a pre-release. I'll test for the next day or two both this and Exhibitor (and clean up both), and I intend to make this a LWRP, probably maintaining a default recipe to keep backwards-compatibility.

Supercedes #76

[wolf31o2]

I would be interested in helping with this. I was thinking of having source and package recipes, which would allow for keeping the current zookeeper source-based approach, and adding package-based approaches for native (Ubuntu, anyway), CDH, and HDP packages.

[jakedavis]

I think that's a good feature to add. For now, I'd like to keep the scope to implementing the default recipe as an LWRP (which I'm about done with). We can build from there. I agree a zookeeper_config resource would also be good, as would the ability to install from source or package.

[jakedavis]

https://github.com/SimpleFinance/chef-zookeeper/issues/75

[miah]

This looks good @jakedavis =)

[jakedavis]

The scope here has grown a bit. I'm trying to add a VERY basic zookeeper_service resource which will basically just zkServer.sh start. This doesn't give us any supervision, but that can be added (figure the Runit path first). I'm also building out some scaffolding for zookeeper_config, and I'll probably commit the shell with some log statements saying its unimplemented.

I'll also do some doc updates in a separate PR.

[wolf31o2]

I have template-based config in the continuuity/hadoop_cookbook repo. The zookeeper_server recipe. Feel free to borrow anything... :-)

[jakedavis]

Okay sorry for the comment spam here. I am going to move forward with it as-is, minus some updates on the zookeeper resource I have locally and am testing now. I realized this cookbook presently makes no effort to manage the ZK service, so that should be a separate PR.

@wolf31o2, for sure. I think I'd like to render the config without a template, but I read through briefly and I think there's still quite a bit of overlap.

[jakedavis]

Alright, test-kitchen succeeded, we're on Berks 3, and I believe it's mostly backwards-compatible while also factoring out the code from the Exhibitor cookbook (which needs the same treatment).

[jakedavis]

Ugh, I think I did that thing again where I bumped metadata too early, eff.

[jeffbyrnes]

@jakedavis looks like it cam in right here: https://github.com/SimpleFinance/chef-zookeeper/commit/7a8f9ff4759e22ce882a6b76ee2879f8da71ac36#diff-9fd042d4cd1e8f82894bbd7dffb313ecR6.

[jakedavis]

Blehhhh okay I think I can fix it, got another thing at the moment but after that I can hit that up.

[jakedavis]

Aight, got this branch, old-master.

It's the CURRENT master branch. I'm currently deleting master locally, branching off of the commit before merging #76 in, and doing a git cherry-pick --no-commit to each commit, editing metadata.rb to be 1.7.4 each time. I'll then force-push that branch, commit the metadata/CHANGELOG changes, tag, and we'll be good.

[jakedavis]

Fixed :)

[jeffbyrnes]

@jakedavis nicely done. For future, you could have a similar effect by using git rebase -i and specify the commit hash just before the merge occurred. This would let you squash commits together, and even edit commits as you rebase. Would have had a similar result to how you did it, but perhaps with less effort.

Very much appreciated though!