Open Stack

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.

--Gordon.