Anil Venkata wrote:
> On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo
> wrote:
> > On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers wrote:
> >> With help from others, I have started an analysis of some of the
> >> different approaches to L3 HA:
> >>
> >> https://ethercalc.openstack.o
On Wed, Feb 22, 2017 at 1:40 PM, Miguel Angel Ajo Pelayo
wrote:
> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> architecture
> in the case of HA, pacemaker is not taking care of those anymore since the
> HA-NG implementation.
>
> We let systemd take care to restart t
>>
>>
>>
>>
>>
>> Just my $.02
>>
>>
>>
>> Cristian
>>
>>
>>
>> *From:* Anna Taraday [mailto:akamyshnik...@mirantis.com]
>> *Sent:* Monday, February 13, 2017 11:45 AM
>> *To:* OpenStack Development Mailing List
On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:
> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> architecture
> in the case of HA, pacemaker is not taking care of those anymore since the
> HA-NG implementation.
>
> We let system
I have updated the spreadsheet. In the case of RH/RDO we're using the same
architecture
in the case of HA, pacemaker is not taking care of those anymore since the
HA-NG implementation.
We let systemd take care to restart the services that die, and we worked
with the community
to make sure that age
Kosnik, Lubosz wrote:
> About success of RDO we need to remember that this deployment utilizes
> Peacemaker and when I was working on this feature and even I spoke with Assaf
> this external application was doing everything to make this solution working.
> Peacemaker was responsible for checkin
About success of RDO we need to remember that this deployment utilizes
Peacemaker and when I was working on this feature and even I spoke with Assaf
this external application was doing everything to make this solution working.
Peacemaker was responsible for checking external and internal connecti
If I propose some concrete solution that will be discussion about one
solution not about making things flexible.
At first I wanted to propose some PoC for other approach, but during my
experiments I understood that we may have different approaches, but for all
of them we need pluggable HA router in
On Fri, Feb 10, 2017 at 12:27 PM, Anna Taraday
wrote:
> Hello everyone!
>
> In Juno in Neutron was implemented L3 HA feature based on Keepalived (VRRP).
> During next cycles it was improved, we performed scale testing [1] to find
> weak places and tried to fix them. The only alternative for L3 HA
ck-dev@lists.openstack.org>>
Date: Monday, February 13, 2017 at 10:23 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA
So from my pers
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 fo
>
>
>
> Cristian
>
>
>
> *From:* Anna Taraday [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 H
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
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 wrote:
> Hi, we are usi
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 da
Hello everyone!
In Juno in Neutron was implemented L3 HA feature based on Keepalived
(VRRP). During next cycles it was improved, we performed scale testing [1]
to find weak places and tried to fix them. The only alternative for L3 HA
with VRRP is router rescheduling performed by Neutron server, bu
16 matches
Mail list logo
