Hi Mark, Thanks for the response! Some further followup inline...
On 12/09/2013 09:53 PM, Mark McLoughlin wrote:
It's not a completely unreasonable approach to take, but my thinking was that a transport URL connects you to a conduit which multiple applications could be sharing so you need the application to specify its own application namespace.
I agree with the general picture, I was just wondering whether the application is best placed to specify its own namespace.
e.g. you can have 'scheduler' topics for both Nova and Cinder, and you need each application to specify its exchange whereas the administrator is in full control of the transport URL and doesn't need to worry about application namespacing on the transport.
I can see the value in simplifying things for the administrator by default.
There are three ways the exchange appears in the API: 1) A way for an application to set up the default exchange it operates in: messaging.set_transport_defaults(control_exchange='nova') http://docs.openstack.org/developer/oslo.messaging/transport.html#oslo.messaging.set_transport_defaults 2) The server can explicitly say what exchange its listening on: target = messaging.Target(exchange='nova', topic='scheduler', server='myhost') server = messaging.get_rpc_server(transport, target, endpoints) http://docs.openstack.org/developer/oslo.messaging/server.html#oslo.messaging.get_rpc_server 3) The client can explicitly say what exchange to connect to: target = messaging.Target(exchange='nova', topic='scheduler') client = messaging.RPCClient(transport, target) http://docs.openstack.org/developer/oslo.messaging/rpcclient.html#oslo.messaging.RPCClient But also the admin can override the default exchange so that e.g. you could put two instances of the application on the same transport, but with different exchanges.
I guess I'm saying (thinking aloud?) that if you have this ability (and indeed this need), then why not take the responsibility out of the application altogether?
Where an application chooses the exchange itself, is that usually hardcoded? or would that also be a configuration item, albeit of the application and not the transport? I assume the override applies on to item (1) above?
Now, in saying all that, we know that fanout topics of the same name will conflict even if the exchange name is different: https://bugs.launchpad.net/oslo.messaging/+bug/1173552 So that means the API doesn't work quite as intended yet, but I think the idea makes sense. I'm guessing you have a concern about how transports might implement this application namespacing? Could you elaborate if so?
Not really, though the mechanisms available may vary from one transport to another. I don't really have any real concerns with things as they are.
My motivation, if that is the right word, was really just around simplicity. I was originally confused by what appeared to be multiple different ways to disambiguate names and thought this suggestion might simplify things overall a little. However as you point out it make it less simple for the administrator.
--Gordon _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev