Open Stack

On 22/06/15 06:39 PM, Chris Dent wrote:
> On Mon, 22 Jun 2015, Sean Dague wrote:
>
>> Could we deprecate the use of tranport_url in ceilometermiddleware and
>> move to an actual oslo.config file somewhere instead? That would bring
>> it in line with the rest of the RPC configuration for services, and
>> ensure that all connections in a cluster have access to all the same
>> options.
>
> Replying on the top of the thread as it seems the responses have taken
> us on a bit of a journey and I feel like instead of narrowing the goal
> and figuring out what to do we've expanded scope and need to fix
> everything. We can't fix everything so let's back up a bit and figure
> out the original goal.
>
> When you (Sean) and I first talked about this I understood the problem
> to be that the use of just a URL was insufficient for covering the
> configuration settings of the various messaging solutions and
> additionally was not in keeping with convention.
>
> I poked around in the code and discovered (as has been mentioned
> elsewhere in the thread) the filter factory configuration settings are
> merged into the oslo config.
>
> So: is it appropriate, for now, to switch devstack:lib/swift to write
> long form transport configuration in filter:ceilometer of swift
> proxy's config (it's already writing plenty of other stuff) and kill
> get_transport_url. ceilometermiddleware already calls get_transport
> with a cfg.CONF that will be used for figuring out the transport url
> if 'url' is None.

what's 'long form transport'?

it's not actually using cfg.CONF. to figure out transport url if not 
present. cfg.CONF passed in has nothing set and is basically just a 
bunch of defaults... the url obviously doesn't have a default so 
ceilometermiddleware will fail if you don't pass in a url.

>
> This doesn't solve every extant issue but it does solve some of them.
>
> The ceilometer middleware, whether the old one that was in the
> ceilometer tree or this newer one, has always struggled to exist
> correctly in that weird intersection between swift and the rest of the
> openstack universe, but exist it does in its not quite correct way.
> Whatever we can do to make it exist better, even if its just a little
> bit better, is good.

-- 
gord