<br><br><div class="gmail_quote">On Wed, Feb 20, 2013 at 8:34 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Feb 20, 2013 at 02:14:31PM +0100, Julien Danjou wrote:<br>
> Hi,<br>
><br>
> Context: Ceilometer provides a special notifier driver for Nova,<br>
> publishing the last counters before an instance get destroyed.<br>
><br>
> That means this code is run from `nova-compute' and uses some Ceilometer<br>
> code. The problem is that when importing Ceilometer modules from this<br>
> notifier, it ends up importing `ceilometer.openstack.common.rpc', which<br>
> tries to register the `rpc_backend' option inside<br>
> `oslo.config.cfg.CONF', object which already has this option defined by<br>
> nova.openstack.common.rpc. So `DuplicateOptError' is raised, and<br>
> badaboum.<br>
><br>
> It's likely we're a unique case because most projects using their own<br>
> copy of oslo don't mix, but we do, and we're facing a regression now<br>
> that oslo.config has been released in the wild.<br>
<br>
</div>IMHO the core issue here is that Ceilometer should not be putting<br>
its code into Nova. Any code that is intended to run inside Nova<br>
processes should be part of the Nova GIT repo, not the ceilometer<br>
GIT repo. By mixing code from two projects you are exposing both<br>
projects to each others' internal implementation details. Any<br>
integration between the projects should be exclusively via well<br>
defined RPC / REST APIs interfaces, rather than dropping in chunks<br>
of external code.<br></blockquote><div><br></div><div>The notifier API is supposed to be a hook point for other projects to inject code, isn't it?</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This similar kind of problem was seen with Quantum where the Quantum<br>
GIT repo held a number of VIF driver plugins for Nova, and these<br>
VIF drivers hardcoded specific knowledge of Quantum requirements.<br>
Of course when Nova code was refactored, this broke all the VIF<br>
drivers stored in Quantum. The fix (which is partially complete)<br>
was to define a clear RPC interface between Quantum & Nova and so<br>
de-couple Nova VIF driver implementations from needing to hardcode<br>
any direct knwoledge of Quantum & vica-verca.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br>