Open Stack

Hi Gordon,

On Fri, 2013-12-06 at 18:36 +0000, Gordon Sim wrote:
> On 11/18/2013 04:44 PM, Mark McLoughlin wrote:
> > On Mon, 2013-11-18 at 11:29 -0500, Doug Hellmann wrote:
> >> IIRC, one of the concerns when oslo.messaging was split out was
> >> maintaining support for existing deployments with configuration files that
> >> worked with oslo.rpc. We had said that we would use URL query parameters
> >> for optional configuration values (with the required values going into
> >> other places in the URL)
> [...]
> > I hadn't ever considered exposing all configuration options via the URL.
> > We have a lot of fairly random options, that I don't think you need to
> > configure per-connection if you have multiple connections in the one
> > application.
> 
> I certainly agree that not all configuration options may make sense in a 
> URL. However if you will forgive me for hijacking this thread 
> momentarily on a related though tangential question/suggestion...
> 
> Would it make sense to (and/or even be possible to) take the 'exchange' 
> option out of the API, and let transports deduce their implied 
> scope/namespace purely from the transport URL in perhaps transport 
> specific ways?
> 
> E.g. you could have rabbit://my-host/my-virt-host/my-exchange or 
> rabbit://my-host/my-virt-host or rabbit://my-host//my-exchange, and the 
> rabbit driver would ensure that the given virtualhost and or exchange 
> was used.
> 
> Alternatively you could have zmq://my-host:9876 or zmq://my-host:6789 
> to 'scope' 0MQ communication channels. and hypothetically 
> something-new://my-host/xyz, where xyz would be interpreted by the 
> driver in question in a relevant way to scope the interactions over that 
> transport.
> 
> Applications using RPC would then assume they were using a namespace 
> free from the danger of collisions with other applications, but this 
> would all be driven through transport specific configuration.
> 
> Just a suggestion based on my initial confusion through ignorance on the 
> different scoping mechanisms described in the API docs. It may not be 
> feasible or may have negative consequences I have not in my naivety 
> foreseen.

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.

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.

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.

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?

Thanks,
Mark.