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

Doug Hellmann doug.hellmann at dreamhost.com
Wed Feb 20 14:02:22 UTC 2013


On Wed, Feb 20, 2013 at 8:34 AM, Daniel P. Berrange <berrange at redhat.com>wrote:

> On Wed, Feb 20, 2013 at 02:14:31PM +0100, Julien Danjou wrote:
> > Hi,
> >
> > Context: Ceilometer provides a special notifier driver for Nova,
> > publishing the last counters before an instance get destroyed.
> >
> > That means this code is run from `nova-compute' and uses some Ceilometer
> > code. The problem is that when importing Ceilometer modules from this
> > notifier, it ends up importing `ceilometer.openstack.common.rpc', which
> > tries to register the `rpc_backend' option inside
> > `oslo.config.cfg.CONF', object which already has this option defined by
> > nova.openstack.common.rpc. So `DuplicateOptError' is raised, and
> > badaboum.
> >
> > It's likely we're a unique case because most projects using their own
> > copy of oslo don't mix, but we do, and we're facing a regression now
> > that oslo.config has been released in the wild.
>
> IMHO the core issue here is that Ceilometer should not be putting
> its code into Nova. Any code that is intended to run inside Nova
> processes should be part of the Nova GIT repo, not the ceilometer
> GIT repo. By mixing code from two projects you are exposing both
> projects to each others' internal implementation details. Any
> integration between the projects should be exclusively via well
> defined RPC / REST APIs interfaces, rather than dropping in chunks
> of external code.
>

The notifier API is supposed to be a hook point for other projects to
inject code, isn't it?

Doug


>
> This similar kind of problem was seen with Quantum where the Quantum
> GIT repo held a number of VIF driver plugins for Nova, and these
> VIF drivers hardcoded specific knowledge of Quantum requirements.
> Of course when Nova code was refactored, this broke all the VIF
> drivers stored in Quantum. The fix (which is partially complete)
> was to define a clear RPC interface between Quantum & Nova and so
> de-couple Nova VIF driver implementations from needing to hardcode
> any direct knwoledge of Quantum & vica-verca.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org              -o-             http://virt-manager.org:|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc:|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130220/ab3f0b67/attachment.html>


More information about the OpenStack-dev mailing list