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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
