Open Stack

Hi Julien,

On Mon, 2013-11-18 at 11:05 +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.

Scared, heh :)

> I've created a blueprint² as requested by Mark.

Ok, so it's a ceilometer blueprint and says:

  "The goal of this blueprint is to be able to use oslo.messaging
   without using a configuration file/object, while keeping its usage
   possible and not breaking compatibility with OpenStack applications."

Why is that important to ceilometer? Ceilometer heavily uses the RPC
code already and uses the config object.

Is this about allowing Ceilometer to consume from multiple brokers?
Where will the configuration be stored for each broker connection? In
the ceilometer database? Why won't transport URLs be sufficient for that
use case given that we know it works fine for Nova cells?

I'm struggling to care about this until I have some insight into why
it's important. And it's a bit frustrating to have to guess the
rationale for this. Like commit messages, blueprints should be as much
about the why as the what.

> That seems necessary since it will be spread on several patch.

It's not about multiple patches, it's about something which needs to be
designed and thought through in advance.

> 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.

As I said in the review, I'm totally fine with the idea of allowing
oslo.messaging to be used without a configuration object ... but I think
the common use case is to use it with a configuration object and I don't
want to undermine the usability of the library in the common use case.

One way of approach this would be to describe how the new API would look
like from the perspective of Nova[1] - i.e. if you are using a config
object, what does the API look like?

The other thing I want to figure out is how we expose the configuration
options in the API in a way that allows us to maintain API compatibility
as we move and rename the config options. That's doable, but needs some
thought.

Thanks,
Mark.

[1] - https://review.openstack.org/39929