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