<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 08/10/2012 12:25 AM, Dan Wendlandt wrote:
<blockquote
cite="mid:CA+0XJm9vRVEhjDhCFg3H8_2688WX3A4oj6kfYFY+D5UM-WCwQw@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Thu, Aug 9, 2012 at 1:13 PM, Mark
McClain <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mark.mcclain@dreamhost.com" target="_blank">mark.mcclain@dreamhost.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
All-<br>
<br>
I wanted to widen the discussion that we've been having on <a
moz-do-not-send="true"
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>
</blockquote>
<br>
I agree that the standard notification would be better. I
nonetheless have a number of reservations regarding the existing
notifications mechanism. This may be due to my misunderstanding of
things or not being familiar enough with the implementation and use
cases. My gut feeling is that the current notification mechanism
from openstack common can be used for monitoring and billing. I do
not think that this suited for what we would like to do and achieve.
Say for example that the user updates a subnet name. This means that
a start and end message will be sent to the agent. More specifically
the agent may only be interested in receiving an update if a
specific field of the subnet has changed. <br>
<br>
I think that we can certainly find a good solution in the long run
and would be happy to discuss and work on this for Grizzly. Needless
to say we need a short term solution for F-3. I personally am in
favor of a simple fanout cast without using the notification
mechanism (option #2). In addition to the notification mechanism may
not have have support for the extensions or require authorization
for extensions. This infomation can be added by the self managed
messaging...<br>
<br>
Thanks<br>
Gary<br>
<br>
<blockquote
cite="mid:CA+0XJm9vRVEhjDhCFg3H8_2688WX3A4oj6kfYFY+D5UM-WCwQw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>Dan</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>