Re: [openstack-dev] TransportURL and virtualhost/exchnage (was Re: [Oslo] Layering olso.messaging usage of config)

2013-12-10 Thread Gordon Sim

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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] TransportURL and virtualhost/exchnage (was Re: [Oslo] Layering olso.messaging usage of config)

2013-12-09 Thread Mark McLoughlin
Hi Gordon,

On Fri, 2013-12-06 at 18:36 +, 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.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev