Open Stack

> I'm the primary author of the ZeroMQ driver.

Thanks for responding to my query.  I have been researching this topic
in detail, so I've been reading your mailing list posts since March,
pulled down your github repo, and watched your overdubbed summit ZMQ
presentation. So I feel like I've been stalking you for the past 6
hours :)

To make it not so terribly one sided.  I'm Rick Richardson, I am
researching dynamic compute and storage solutions for my employer for
the past couple months.  I've been involved in high performance
clustered or peer to peer computing for the last decade, give or take.

>
> The concept of the matchmaker is such that the queryable service is
> abstracted away. In fact, with the ServiceGroup API feature which has
> recently landed in Grizzly, we now have MySQL and Zookeeper backends that
> can power (or replace) the MatchMaker. One of my goals for Grizzly is to
> bridge these features, either by replacing the matchmaker outright, or
> creating a backend dependent on the ServiceGroup API.
>

The ServiceGroup API sounds like just the ticket.  We are leveraging
Ceph for the storage of snapshots and images. The ceph mon nodes are
present on all cloud controller nodes in our system, and ceph osds are
present on all nodes. I was hoping to utilize its mature
implementation membership quorum of both mon nodes and storage nodes
for cloud controllers and compute nodes respectively.  Odds are all of
the discovery data will go into RADOS, since that's a convenient
location and I trust it more than clustered mysql implementations.

>
> Keep in mind we do need to maintain compatibility with AMQP, especially
> since just about everyone is actually using RabbitMQ (but there ARE people
> using the ZeroMQ driver).  With Rabbit, the node that joins creates its own
> topic and in subscribing to any shared topics for which it receives
> messages. I'm actually okay with this pattern, although it does mean we need
> a dynamic membership solution as soon as we can get it. What I implemented
> for Folsom was entirely static, but it was suitable for Nova's broadcast
> pattern where there were very small and fairly static sets of consumers of
> those broadcast messages (namely: schedulers).

I've read the AMQP guide and your blog post on required messaging
guarantees, but the actual (used) messaging types are actually
something I need to learn more about.

E.g. is there a point in pub/sub at all when really what we need are a
bunch of point-to-point links?
And how do the schedulers leverage broadcast exactly?