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. 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. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
