<div dir="ltr">Emilien,<div><br></div><div>thanks for sharing this, which I reckong is going to be a very interesting discussion at the next summit.</div><div>Of the two alternatives, I tend to prefer the latter as it is capable of handling better failover; it would be good if you could more details about the failover procedure; in the document you mention that failover for internal and gateway interface should be synchronized; it would be great to understand how you're planning to do that.</div>
<div><br></div><div>Another aspect to consider is how this relates to nova-network's multi-host feature, which is, in my understanding, the only bit missing from making nova-network features a complete subset of neutron's features. Other than HA and failover, the multi host feature provides also a load distribution capability. Is that something that can be incorporated in your proposal?</div>
<div><br></div><div>Regards,</div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 September 2013 12:13, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien.macchi@enovance.com" target="_blank">emilien.macchi@enovance.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The current implementation of Neutron L3 agent allows us to scale<br>
virtual routers on multiple agents but does not provide High<br>
Availability on :<br>
- namespaces, virtual interfaces (both in north and south)<br>
- established connections between external & internal network.<br>
<br>
The idea here is to start a discussion about a new design that we could<br>
implement in the next release.<br>
Since there exists some conversations on this topic, I want to share my<br>
ideas with a public document we wrote [1] with my team.<br>
<br>
Table of contents:<br>
- Abstract about current implementation<br>
- Current Architecture<br>
- Proposal #1: Health-check (which is not my final solution, but just an<br>
existing way).<br>
- Proposal #2: VRRP + conntrackd (new backends for improving L3 agent)<br>
- Design session proposal for next Summit<br>
<br>
<br>
Feel free to bring your thoughts.<br>
After the discussion, maybe could we write new blueprints.<br>
<br>
Note: the document is public and you are allowed to comment. If you need<br>
more access, I can of course grant you write rights.<br>
<br>
[1]<br>
<a href="https://docs.google.com/document/d/1DNAqRSOIZPqUxPVicbUMWWuRBJ90qJjVYe7Ox8rVtKE/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1DNAqRSOIZPqUxPVicbUMWWuRBJ90qJjVYe7Ox8rVtKE/edit?usp=sharing</a><br>

<br>
<br>
Regards,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Emilien Macchi<br>
----------------------------------------------------<br>
# OpenStack Engineer<br>
// eNovance Inc.              <a href="http://enovance.com" target="_blank">http://enovance.com</a><br>
// ✉ <a href="mailto:emilien@enovance.com">emilien@enovance.com</a>     ☎ <a href="tel:%2B33%20%280%291%2049%2070%2099%2080" value="+33149709980">+33 (0)1 49 70 99 80</a><br>
// 10 rue de la Victoire 75009 Paris<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>