Open Stack

> 
> I'd rather not mix and match. If the host value is just a way to limit the recipient of the message going to topic (or to have the sender choose instead of message broker), then the fact that we define a separate queue for that is an implementation detail of the driver, just like the fact that the ZMQ driver doesn't have a broker, but is always communicating point-to-point. 
> 
> > 
> 

I'm saying that the topic is an arbitrary identifier for messages set by the application. It can include the host if it wants to, it shouldn't matter. Presently, it *does* matter, although users of the API don't seem to know this.
> OK, so host is intended to be the sort of thing you could pass as part of an address when creating a socket. If we make the host argument to ConnectionFactory.__call__ optional then the topic values can be consistent (i.e., not include the host) and the caller can still control who receives the message by constructing the Connection appropriately. That way the semantics of the call are controlled by the right arguments. The topic says "the message is about this" and the host limits the "audience" that gets the message.
To confirm: what you're suggesting is that if we know we're sending a message to a host, we construct a connection to that host -- although that doesn't necessarily map 1:1 to either AMQP or ZeroMQ connections? If so, that seems a possible solution, as long as we can get that users to do use it correctly.

> cf = make_connection_factory(cfg.CONF, cfg.CONF.rpc.driver_name)
> c = cf(host)
> response = c.call(topic, message)




In this model, every message from a scheduler to a compute node will look like:

> c = cf(compute_host)
> response = c.call('compute', {}) 
> 
> 
> 


How would round-robin messages look where the host is not known in advance? It would use a global namespace as present? Unless you intend to make factories for sending to topics, too...

Regards,
Eric Windisch