Open Stack

On 13 February 2017 at 23:23, Kosnik, Lubosz <lubosz.kosnik at intel.com>
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 <akamyshnikova at 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.calin at 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:akamyshnikova at 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 <changzhi1990 at 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-request at lists.openstack.org?subject:
>> unsubscribe
>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:
>> unsubscribe
>> <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170222/cd1e8f3c/attachment.html>