<br><br><div class="gmail_quote">On Thu, Aug 9, 2012 at 1:13 PM, Mark McClain <span dir="ltr"><<a href="mailto:mark.mcclain@dreamhost.com" target="_blank">mark.mcclain@dreamhost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


All-<br>
<br>
I wanted to widen the discussion that we've been having on <a href="https://review.openstack.org/#/c/10997/" target="_blank">https://review.openstack.org/#/c/10997/</a><br>
<br>
Basically the DHCP Agent needs to be notified about certain Quantum events.  There are two ways of accomplishing this:<br>
<br>
1) Turn on Quantum notifications and have the agent consume the general notifications.  Moving forward this would require that rabbit_notifications always be enabled in quantum.conf.<br>
<br>
Pro: This functionality already exists in Quantum.<br>
Con: These messages are more general, so the agent typically has to collect some data in response to the calls.<br></blockquote><div><br></div><div>This is my preference, as I think it leads to a cleaner design and avoid a bunch of specific notifications within Quantum.  I'd really like something like DHCP to be implemented in a way that is basically agnostic to the plugin that is running (i.e., consuming standard notifications, and interacting via the main Quantum API).   This let's people build additional such services (e.g., integrating quantum IPAM with DNS) without modifying the core code.  </div>


<div><br></div><div>We actually had a substantial thread on this topic a few weeks ago in the context of plugin-agents, and the concern was that there currently wasn't a channel other than RPC to pass some information (e.g., the VLAN a network maps to), so we said that for F-3 plugins could create their own RPC mechanisms if needed.  That said, I'd still like to see things more toward a model where we use "standard" notifications.</div>


<div><br></div><div>Dan</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Note: The rabbit_notifier actually works will all of the messaging backends, i.e. qpid.)  These messages are more general in nature and just provide the data returned from the plugin.<br>
<br>
2) Create specific RPC calls that q-svc fans out to the DHCP agent(s).<br>
<br>
Pro: This approach means that the Quantum server can send messages that are specifically tailored for the DHCP agent to act upon.<br>
Con: Essentially implements a subset of the notification API in a specific way.<br>
<br>
I'm open to either approach, but would like the community's input. Thoughts?<br>
<br>
mark<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>


~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>