On 13 February 2017 at 23:23, Kosnik, Lubosz <[email protected]> wrote:
> 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]. > I am pretty sure it wasn't our intentions to 'kill' your ideas, but otherwise set you on the right path for fixing the bug. I still believe that a complete and robust L3 HA solution cannot be built solely with Neutron alone, and that's what I was trying to say with the comment referenced below. > > 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 <[email protected]> > 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 <[email protected]> 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:[email protected]] >> *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 <[email protected]> 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: [email protected]?subject: >> unsubscribe >> <http://[email protected]/?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: [email protected]?subject: >> unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > -- > Regards, > Ann Taraday > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
