Open Stack

On 08/15/2012 04:28 PM, Eric Windisch wrote:
>>>>
>>>> Some questions we had were:
>>>> * Is it possible to use the old-style polling, or to make it optional?
>>>
>>> Yes. In the agent configuration file there is a flag 'rpc'. By default
>>> this is True. If you want you can set this as False. This is supported
>>> in the l2 agents. It is not supported by the dhcp agent.
> 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?

The notifications are only required if the dhcp agent is used. That is, 
the DHCP agent only works with the RPC mechanism.

>>> There are two type of fanout messages that are used. The first is with
>>> the l2 agents in the event that a port or network is updated. The
>>> second is via the openstack common notifier module.
>
> The l2 agents are only consuming (not sending) the rpc.fanout 
> messages, yes? I assume they're sending the notifications, though?

The agent requests information and it receives updates:
Requests (via rpc call):
- 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.
- when the agent detects that a interface has been removed it "tells" 
the plugin.
Updates (the plugin will notify the agent via a fanout cast):
- network deletion
- port state update


>>> The is used by the
>>> dhcp agent. I am not 100% sure if the notifier module supports Zero MQ
>>>
> 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:
>
>  "%s.%s" % (topic, priority)
>
> 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)
>
> Where are these notifications being consumed?

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.

>>> I have yet to understand the problems with the RabbitMq and Qpid vs
>>> Zero MQ. Are these scale issues, performance, stability? It would be
>>> interesting to try and know what the problems are.
> 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.

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?

>
> Regards,
> Eric Windisch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120815/c5aea667/attachment-0001.html>