Open Stack

Hi,
Sadly I was not at the unconference session at the summit. I have been 
thinking about this for quite a while. I will focus on the L3 agent as I 
think that this is the real issue. I think that the DHCP agent has 
problems of its own [1]. My understanding is that there are a number of 
problems (please feel free to add to help me understand what I missing):
- scalability - we do not want the L3 agent to be the bottleneck
- high availability - if the L3 agent goes down then there will be no 
external access to VM's
I am wondering if we can tackle the problem with a different approach - 
without having to make any changes in the Quantum API's and run multiple 
L3 agents (with the same configuration). I think that this can be done 
in the following manner:
1. HA for the L3 agents - this can be achieved by using VRRP 
(http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol).
2. Scale - when traffic is sent from the nodes to the L3 agent for 
floating IP's we change the destination MAC address to the MAC address 
of the L3 agent. This will make the L3 agents transparent. Each plugin 
can offer this support - for example if one is using OpenvSwitch then a 
flow entry can be created that will override the destination MAC. For 
the linux bridge I assume that this can be done by the tcpbridge interface.
In both of the above cases we will need to have some kind of health 
check (a process on each node checking ICMP or ARP's to the L3 agent). 
This can and should be added to Nova to ensure that there is 
connectivity between the compute node and the L3 agent. If a failure of 
connectivity is detected then the "flows" can be rebuilt to ensure that 
the traffic is redirected to another L3 agent.
Is this worthwhile exploring?
Thanks
Gary

[1] The DHCP agent listens to notification - a tap device and namespace 
(to provide overlapping IP's) will be created for each network. In the 
case of dnsmasq a process will be run to provide the DHCP service. I 
wonder what the limits are for the amount of networks that can be 
supported. It may be worth considering limiting.