Open Stack

Hi, 

On Mon, Nov 18, 2013 at 11:05:20AM +0100, Julien Danjou wrote:
> Hi Oslo developers,
> 
> It seems my latest patch¹ on oslo.messaging scared Mark, so I'll try to
> discuss it a bit on this mailing list as it is more convenient.
> 
> I've created a blueprint² as requested by Mark. That seems necessary
> since it will be spread on several patch.
> 
> Now to the core. oslo.messaging API mixes usage of parameters and
> configuration file object. Such as you have to provide a configuration
> object for basic API usage, even if you don't have a configuration
> object.
> 
> It seems to me that having this separation of concerns in oslo.messaging
> would be good idea. My plan is to move out the configuration object out
> of the basic object, like I did in the first patch.
> 
> I don't plan to break the configuration handling or so, I just think it
> should be handled in a separate, individually testable part of the code.
> 
> Ultimately, this would allow oslo.messaging to not be 'oslo' only, and
> just being friendly with oslo.config and therefore OpenStack. A goal I
> wish we'd had in more oslo library. :)

I like the idea of separate the oslo.config stuffs.

I have started to replace oslo.rpc by oslo.messaging in ceilometer.
And I have two cases that this idea will helped.

* Currently oslo.messaging register opts when a object that
  needs the opt is created, this have too side effets:
    - we cannot use import_opt to get this option outside oslo.messaging,
    - the tools generate_samples seems not catch this opts anymore.
  This force me to register all rpc needed opts in ceilometer and if oslo.messaging
  change one of them, ceilometer will be not broke automatically, like it does currently.

* A more interesting one, this split will permits to easly create a piece of
  code that can build transport url from the legacy opt configuration (ie:
  rpc_backend) instead of rewritting the compatibility
  layer in each project.


Regards, 
-- 
Mehdi Abaakouk
mail: sileht at sileht.net
irc: sileht
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/b87b18b5/attachment.pgp>