So from my perspective I can tell that problem is completely in architecture 
and even without something outside of Neutron we cannot solve that.
Two releases ago I started to work on hardening that feature but all my ideas 
was killed by Armando and Assaf. The decided that adding outside dependency 
will open the doors for a new bugs from dependencies into Neutron [1].

You need to know that there are two outstanding bugs in this feature. There is 
a internal and outside connectivity split brain. [2] this patch made by me is 
“fixing” part of the problem. It allows you specify additional tests to verify 
connectivity from router to GW.
Also there is a problem with connectivity between network nodes. It’s more 
problematic and like you said it’s unsolvable in my opinion without using 
external mechanism.

If there will be any need to help with anything I would love to help with 
sharing my knowledge about this feature and what exactly is not working. If 
anyone needs any help with anything about this please ping me on email or IRC.

[1] https://bugs.launchpad.net/neutron/+bug/1375625/comments/31
[2] https://review.openstack.org/#/c/273546/

Lubosz

On Feb 13, 2017, at 4:10 AM, Anna Taraday 
<akamyshnik...@mirantis.com<mailto:akamyshnik...@mirantis.com>> wrote:

To avoid dependency of data plane on control plane it is possible to deploy a 
separate key-value storage cluster on data plane side, using the same network 
nodes.
I'm proposing to make some changes to enable experimentation in this field, we 
are yet to come up with any other concrete solution.

On Mon, Feb 13, 2017 at 2:01 PM 
<cristi.ca...@orange.com<mailto:cristi.ca...@orange.com>> wrote:

Hi,





We also operate using Juno with the VRRP HA implementation and at had to patch 
through several bugs before getting to the Mitaka release.

An pluggable, drop-in alternative would be highly appreciated. However our 
experience has been that the decoupling of VRRP from the control plane is 
actually a benefit as when the control plane is down the traffic is not 
affected.

In a solution where the L3 HA implementation becomes tied to the availability 
of the control plane (etcd cluster or any other KV store) then an operator 
would have to account for extra failure scenarios for the KV store which would 
affect multiple routers than the outage of a single L3 node which is the case 
we usually have to account now.





Just my $.02



Cristian



From: Anna Taraday 
[mailto:akamyshnik...@mirantis.com<mailto:akamyshnik...@mirantis.com>]
Sent: Monday, February 13, 2017 11:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA



In etcd for each HA router we can store key which will identify which agent is 
active. L3 agents will "watch" this key.
All these tools have leader election mechanism which can be used to get agent 
which is active for current HA router.



On Mon, Feb 13, 2017 at 7:02 AM zhi 
<changzhi1...@gmail.com<mailto:changzhi1...@gmail.com>> wrote:

Hi, we are using L3 HA in our production environment now. Router instances 
communicate to each other by VRRP protocol. In my opinion, although VRRP is a 
control plane thing, but the real VRRP traffic is using data plane nic so that 
router namespaces can not talk to each other sometimes when the  data plan is 
busy. If we were used etcd (or other), does every router instance register one 
"id" in etcd ?





Thanks

Zhi Chang

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Regards,
Ann Taraday

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Regards,
Ann Taraday
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to