Open Stack

On 08/15/2012 08:41 AM, Gary Kotton wrote:
> On 08/15/2012 04:58 AM, Eric Windisch wrote:
>>
>> On Tuesday, August 14, 2012 at 20:39 PM, Dan Wendlandt wrote:
>>
>>>
>>> Eric mentioned that there are some issues with the new RPC code with 
>>> the ZeroMQ driver, due to the code's use of fanout().  Eric can 
>>> explain it better to me, but because ZeroMQ does not have a 
>>> centralized server, it would need to know the IP addresses of each 
>>> of the nodes that might receive the fanout message (i.e., each of 
>>> the hosts running the agent).  When using the OVS plugin, we kind of 
>>> have this, but we don't have the equivalent for LB or for the DHCP 
>>> agent.  Eric is going to outline some of the potential fixes he sees 
>>> and we can discuss the tradeoffs.
>>
>> Thank you Dan.  I'm also copying Mark McLoughlin of openstack-common.
>>
>> That is correct, each node sending a fanout with ZeroMQ needs to know 
>> the IP addresses of each of the nodes that might receive a message. 
>> Because Nova only used fanout to talk to the scheduler, we were able 
>> to get by with a static mapping stored in a JSON file.  This was to 
>> be addressed by the ServiceGroup patch, but I don't expect it to land 
>> into openstack-common until Grizzly.
>>
>> 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.
>> * How hard would it be to do rpc-based polling as an option? (maybe 
>> this is a middle-ground, rather than keeping two code bases)
>> * Where are the fanout messages sent from? The quantum API server?
>
> 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 is used by the 
> dhcp agent. I am not 100% sure if the notifier module supports Zero MQ
>
> 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.
>>
>> I'm also evaluating a potential change to the ZeroMQ driver, but it 
>> would be a huge time-sink (weeks) and I'm not sure if it would be 
>> really viable once Grizzly+ServiceGroups arrive. I'll hash this out 
>> more...
>>
>> Thank you,
>> Eric Windisch
>