Open Stack

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