Open Stack

Hi Gary

Thank you for posting this.

> 1. HA for the L3 agents - this can be achieved by using VRRP
> (http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol).

IMO, sending garp is enough if we have bulid-in heartbaet method.

> 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.

+1 for that idea.

IMO, this should be done by common service infrastructure by openstack-common.
https://blueprints.launchpad.net/openstack-common/+spec/service-infrastructure
This work is make service.py move to openstack-common.
l3-agent and dhcp-agent should bese this common service infrastructure

Thanks
Nachi

> 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.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev