[openstack-dev] [oslo] Option conflict when mixing projects

Mark McLoughlin markmc at redhat.com
Thu Feb 21 15:03:14 UTC 2013


On Wed, 2013-02-20 at 15:07 +0100, Julien Danjou wrote:
> On Wed, Feb 20 2013, Mark McLoughlin wrote:
> 
> > I don't know exactly what you're trying to achieve here, but if you need
> > different RPC configuration for ceilometer code in nova-compute then you
> > need a separate configuration file and a separate ConfigOpts object
> >
> > Basically, there should be a way to pass an object other than
> > oslo.confg.cfg.CONF to the RPC calls.
> 
> Ok, but the underlying problem is that we don't control what
> openstack.common.rpc does, and it registers its options at import time.
> 
> So how can we, Ceilometer, fix this case:
> 
> >>> import nova.openstack.common.rpc
> >>> import ceilometer.openstack.common.rpc
> 
> on our own?
> 
> (Hint: the answer "don't do that" isn't valid :-))

Ok, I took a poke at this and hacked up a patch that's probably broken
in a million different ways.

The tl;dr is that we can add an rpc.get_impl() function quite easily but
ceilometer will require quite a bit of conf to ensure no code run by
nova_notifer uses cfg.CONF:

  https://github.com/markmc/ceilometer/commits/non-global-conf

    Allow nova_notifier use non-global config
      
    The nova_notifer code runs in the context of nova, so if we use cfg.CONF
    then we are reading options from nova.conf. Instead, we want to read
    config options from ceilometer.conf.
    
    To achieve that, all of ceilometers code which is used by nova_notifier
    needs to accept a ConfigOpts object created by nova_notifier. The code
    needs to both register and read config options from this object.
    
    When we get down to meter_publish, the calls to the oslo RPC code also
    need to be passed this ConfigOpts object. To facilitate this, we add
    a new rpc.get_impl() function which needs to be proposed to
    oslo-incubator.

I've also filed this bug:

  https://bugs.launchpad.net/oslo/+bug/1131233

Cheers,
Mark.




More information about the OpenStack-dev mailing list