Couple slightly more to Zookeeper

[jakedavis]

One thing I've noticed while deploying this and Zookeeper is they don't think about each other very well. That is, you'll render the Zookeeper config, render Exhibitor config using different attributes, and then Exhibitor will run over the Zookeeper config. Exhibitor should probably lean more on Zookeeper attributes so this is less problematic and you'll know what the resultant config will be.

[mwhooker]

Jake, so glad to see you guys still working on this. Feel free to hit me up if you want to brainstorm

Plaese forgive typos -- sent via phone

On Jul 18, 2014, at 15:36, Jake Davis notifications@github.com wrote:

One thing I've noticed while deploying this and Zookeeper is they don't think about each other very well. That is, you'll render the Zookeeper config, render Exhibitor config using different attributes, and then Exhibitor will run over the Zookeeper config. Exhibitor should probably lean more on Zookeeper attributes so this is less problematic and you'll know what the resultant config will be.

— Reply to this email directly or view it on GitHub.

[jakedavis]

Yeah, absolutely! Our big motive has been standing up Kafka again, but it's been a few weeks in progress at this point with other things going on. Pretty excited to mess with it some more though.

[spuder]

I think the cookbook should go the other direction and be less tightly coupled with zookeeper.

For example, currently this cookbook is a sort of wrapper around the zookeeper cookbook.

https://github.com/SimpleFinance/chef-exhibitor/blob/master/recipes/default.rb#L27

This causes problems when trying to use your own wrapper around the zookeeper cookbook LWRP's.

Also, if the cookbook is to be coupled with the zookeeper cookbook, then the dependencies also need to be tightly coupled, or you get dependency loops. (I"m currently fighting this with no luck. See issue #24 )

Unable to satisfy constraints on package zookeeper due to solution constraint (exhibitor = 0.6.0). Solution constraints that may result in a constraint on zookeeper: [(exhibitor = 0.6.0) -> (zookeeper ~> 3.0.0)], [(exhibitor = 0.6.0) -> (zookeeper ~> 2.0)], [(nd-zookeeper = 0.1.0) -> (zookeeper >= 0.0.0)], [(nd-zookeeper = 0.1.0) -> (exhibitor = 0.6.0) -> (zookeeper ~> 3.0.0)], [(nd-zookeeper = 0.1.0) -> (exhibitor = 0.6.0) -> (zookeeper ~> 2.0)], [(nd-zookeeper = 0.1.0) -> (exhibitor = 0.3.0) -> (zookeeper >= 2.0.0)], [(nd-zookeeper = 0.1.0) -> (exhibitor = 0.5.0) -> (zookeeper ~> 2.0)], [(zookeeper = 3.0.0)]
Demand that cannot be met: (exhibitor = 0.6.0)
Artifacts for which there are conflicting dependencies: zookeeper = 3.0.0 -> [(build-essential >= 2.0.2), (java >= 0.0.0), (runit >= 0.0.0), (apt >= 0.0.0), (magic ~> 1.1)]Unable to find a solution for demands: apt (>= 0.0.0), exhibitor (0.6.0), java (>= 0.0.0), nd-zookeeper (0.1.0), zookeeper (3.0.0)

Ways this could be fixed:

1. Completely decouple the exhibitor cookbook from the zookeeper cookbook to allow people to wrap both cleanly.
2. Deprecate this cookbook and move the exhibitor functionality to an optional recipe and/or LWRP inside the zookeeper cookbook

[jeffbyrnes]

@spuder originally, actually, the zookeeper cookbook encompassed all of the functionality of this cookbook. My fault, frankly, for not cutting a new release of this cookbook that works with zookeeper ~> 3.0.

That said, Exhibitor depends on ZooKeeper in general, but you’re right, this should probably drop the zookeeper cookbook as a dependency, and stop including the zookeeper::install recipe, allowing for better usage of the zookeeper cookbook’s custom resources/LWRP.