<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 08/15/2012 04:28 PM, Eric Windisch wrote:
<blockquote
cite="mid:2D4FC87F0B7645F49980F3F2C1A397C9@cloudscaling.com"
type="cite">
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<div>
<div>
<blockquote type="cite">
<div>
<blockquote type="cite">
<div>
<div><br>
</div>
<div>Some questions we had were:</div>
<div>* Is it possible to use the old-style
polling, or to make it optional?</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. In the agent configuration file there is a
flag 'rpc'. By default </div>
<div>this is True. If you want you can set this as
False. This is supported </div>
<div>in the l2 agents. It is not supported by the dhcp
agent.</div>
</div>
</blockquote>
</div>
</div>
</span></blockquote>
<div>Still not our ideal fix, but that would care of the agents,
but what about the notifications? I presume these are still
required even if that rpc flag is off? <br>
</div>
</blockquote>
<br>
The notifications are only required if the dhcp agent is used. That
is, the DHCP agent only works with the RPC mechanism.<br>
<br>
<blockquote
cite="mid:2D4FC87F0B7645F49980F3F2C1A397C9@cloudscaling.com"
type="cite">
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<div>
<div>
<blockquote type="cite">
<div>
<div>There are two type of fanout messages that are
used. The first is with </div>
<div>the l2 agents in the event that a port or network
is updated. The </div>
<div>second is via the openstack common notifier
module.</div>
</div>
</blockquote>
</div>
</div>
</span></blockquote>
<div><br>
</div>
<div>The l2 agents are only consuming (not sending) the rpc.fanout
messages, yes? I assume they're sending the notifications,
though? <br>
</div>
</blockquote>
<br>
The agent requests information and it receives updates:<br>
Requests (via rpc call):<br>
- when the agent detects a new interface it "asks" the plugin via a
RPC for the interface details. When it gets the answer it will
configure the networking accordingly.<br>
- when the agent detects that a interface has been removed it
"tells" the plugin.<br>
Updates (the plugin will notify the agent via a fanout cast):<br>
- network deletion<br>
- port state update<br>
<br>
<br>
<blockquote
cite="mid:2D4FC87F0B7645F49980F3F2C1A397C9@cloudscaling.com"
type="cite">
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<div>
<div>
<blockquote type="cite">
<div>
<div> The is used by the </div>
<div>dhcp agent. I am not 100% sure if the notifier
module supports Zero MQ</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</span></blockquote>
<div>It doesn't. The "rabbit_notifier" is just as it is called.
Really, though, the only thing that makes the Rabbit
notification driver incompatible with ZeroMQ is that it uses a
topic key set as:</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> "%s.%s"
% (topic, priority) </div>
<div><br>
</div>
<div>The ZeroMQ driver would perceive the priority as a
destination host and would try sending all messages to a host
named 'INFO' (or 'ERROR', or whatever other priorities are
defined)</div>
<div><br>
</div>
<div>Where are these notifications being consumed?</div>
</blockquote>
<br>
The notifications are consumed by the DHCP agent. For example when a
port is created and the IP address of the port is in a subnet that
supports DHCP, then the DHCP agent will ensure that the VM that uses
the port will receive its allocated IP address.<br>
<br>
<blockquote
cite="mid:2D4FC87F0B7645F49980F3F2C1A397C9@cloudscaling.com"
type="cite">
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<div>
<div>
<blockquote type="cite">
<div>
<div>I have yet to understand the problems with the
RabbitMq and Qpid vs </div>
<div>Zero MQ. Are these scale issues, performance,
stability? It would be </div>
<div>interesting to try and know what the problems
are.</div>
</div>
</blockquote>
</div>
</div>
</span></blockquote>
<div>The RabbitMQ and Qpid drivers are fairly similar and share a
lot of code, and they're behaviorly similar. I'd compare their
relationship to that of MySQL and PostgreSQL. The ZeroMQ driver
is vastly different, and we're using it in a peer-to-peer model
that introduces some challenges around the subscription model.</div>
</blockquote>
<br>
Ideally we would like to use one common generic interface. Are you
aware of the gaps that need to be addressed to ensure that the
ZeroMQ can be instead of either rabbit or qpid?<br>
<br>
<blockquote
cite="mid:2D4FC87F0B7645F49980F3F2C1A397C9@cloudscaling.com"
type="cite">
<div><br>
</div>
<div>Regards,</div>
<div>Eric Windisch</div>
</blockquote>
<br>
</body>
</html>