Support for Zookeeper

[jamescarr]

I think it'd be great if this could also support zookeeper as well (since it is what we use). I don't know erlang but I'll take a look!

[gmr]

Because zookeeper has it's own protocol, I'm hesitant to add another external dependency to the plugin, but I think i have a good way forward in implementing it. #63 illustrates my thoughts there and once I get the core supporting that behavior, Zookeeper support should be fairly trivial to add.

[ThirukumaranPalani]

I like to Produce and consume Messages in RabbitMQ in Zookeeper. Will it possible to do so

[michaelklishin]

@ThirukumaranPalani please post your questions to rabbitmq-users.

[gmr]

@ThirukumaranPalani based upon my knowledge of ZooKeeper, that's not possible and I think you may be misunderstanding ZooKeeper. This ticket is about using ZooKeeper to store information about what RabbitMQ nodes are available for auto-discovery purposes.

[binelson]

+1. I'd definitely be interested in this as well.

[fogfish]

The usage of ZooKeeper with Erlang applications is dead-end in my opinion. You are using ZK for nodes discovery and assembly of cluster. Erlang has its own protocol(s) http://erlang.org/doc/reference_manual/distributed.html
I do not really see any benefit of ZK it complicates system management, operations and automation. What is you real use-cases for ZK here?

[gmr]

Environments that natively use ZooKeeper would be able to use their pre-existing resources for node discovery instead of setting up something new.

Unless I've missed something, Erlang's standard library does nothing to implement cross-server node discovery. You can form clusters when you know the topology of the cluster -- which nodes exist to communicate with each other.

I'm not interested on bike-shedding over discovery mechanisms. The goal of the plugin is to provide an extendable base for supporting various methods of node discovery for clustering purposes.

[fogfish]

Unless I've missed something, Erlang's standard library does nothing to implement cross-server node discovery. You can form clusters when you know the topology of the cluster -- which nodes exist to communicate with each other.

Sorry, you did. Erlang has built-in feature to discover all cluster nodes to build mesh topology. This requires one or two seed nodes + firewall configuration (same applies to ZK). The "seeding" is very trivial https://github.com/fogfish/ek/blob/new-vnode-struct/src/ek_seed.erl

I can bring a same technique to this project?

[gmr]

If I have three different nodes ['foo@10.0.0.1', 'foo@10.0.0.2', 'foo@10.0.0.2'] are you providing all three nodes in your seed list? If not what's the mfa you're invoking to get the additional nodes when starting on 'foo@10.0.0.1'? erlang:nodes/0?

[gmr]

I think I see what you're doing. Your seed node is the master, all other nodes need to know about it and announce their presence to it on startup, correct? If so, how does your pattern work without a seed node?

[fogfish]

Yes you are right. All nodes needs to know about 'seed' nodes (I would not use term master in this context). You might have only one seed node or two (foo@10.0.0.1, foo@10.0.0.2). This is up to your deployment configuration. The usage of ZK requires the knowledge ZK client nodes for discovery.

Talking about 'seedless' solution... On AWS problem is solved using AWS EC2 group...

[gmr]

Currently the behavior of this plugin is primarily about finding a seed node.

The backends in this plugin allow for finding the seed list and choosing a node from it. Currently supported methods for finding the seed include AWS tags, autoscaling groups, consul, etcd, and DNS. Adding Zookeeper is a way to allow for people with Zookeeper infrastructure to use Zookeeper for finding the seed. I'd also like to see support for mDNS and other gossip based discovery protocols.

We don't replace the native clustering that RabbitMQ uses, using the same mechanism your ek library uses that is built-in.

When i use the term discovery, I mean some sort of way to get the seed list via gossip protocol or external service. I don't believe I missed anything in my initial analysis of what Erlang provides.

As far as using ek as a backend, with the seeding requirement, I'm not sure what the point would be since RabbitMQ manages its cluster communication just fine and we're only finding the seed node that allows clusters to form.

[fogfish]

Yeah, you are right. We just mislead with terminology. Seed discovery is an issue to some extend... I am pretty sure this work gonna be useful for other Erlang project besides RMQ.

[livercat]

Is this functionality still being considered?

[Gsantomaggio]

@michaelklishin @dcorbacho WDYT ? should we investigate it ?

[michaelklishin]

I don't think anyone would object to a reasonable implementation for ZooKeeper. That said, this plugin is currently at https://github.com/rabbitmq/rabbitmq-autocluster and becoming less and less relevant with each day passing towards the RabbitMQ 3.7.0 release, which already supports the same set of backends (via individual plugins such as this).

[michaelklishin]

@Gsantomaggio I feel ZooKeeper users should step up and develop one, given that it's easier to do in a standalone plugin for 3.7.0. Or at least demonstrate that there's enough interest for it.

[gmr]

This plugin was forked by the RabbitMQ team and is now part of RabbitMQ. More information can be found @ https://github.com/rabbitmq/rabbitmq-autocluster