[openstack-dev] [Oslo] Layering olso.messaging usage of config
Mark McLoughlin
markmc at redhat.com
Fri Dec 6 17:15:24 UTC 2013
On Fri, 2013-12-06 at 16:55 +0000, Joshua Harlow wrote:
> I really have to agree with this. It's especially important if
> oslo.messaging is also used in libraries like taskflow. If
> oslo.messaging imposes that users of it must use oslo.config then by
> using it in taskflow, taskflow then imposes the same oslo.config
> usage.
You know, I think you either didn't read my (carefully considered) email
or didn't take the time to understand it. That's incredibly frustrating.
My proposal would mean that oslo.messaging could be used like this:
from oslo import messaging
conf = messaging.get_config_from_dict(dict(rpc_conn_pool_size=100))
transport = messaging.get_transport(conf, 'qpid:///test')
server = Server(transport)
server.start()
server.wait()
oslo.config is nothing but an implementation detail if you used
oslo.messaging in this way.
(Julien had a more subtle concern about this which I can actually relate
more to)
> This makes all libraries that use it inherently only useable in the
> openstack ecosystem which I think is very bad opensource behavior (not
> exactly open).
"bad open-source behaviour"? Seriously?
Yeah, like gtk+ is only usable in the GNOME ecosystem because it uses
glib and gtk+ authors are bad open-source people because they didn't
allow an alternative to glib to be used. Bizarre statement, frankly.
> There are other reasons to, a configuration dict means u can have
> many different active instances being simultaneously used (each with
> its own config), with oslo.config since it is a static configuration
> object u get 1 simultaneous instance. So this is yet another behavior
> that I as a library provider thing is very unhealthy restriction to
> impose on people that use taskflow.
"1 simultaneous instance" ... you mean the cfg.CONF object?
There's no requirement to use that and I explained that in my email
too ... even though I actually thought it should need no explaining at
this point.
Mark.
More information about the OpenStack-dev
mailing list