Open Stack

On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo <
majopela at 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 systemd take care to restart the services that die, and we worked
> with the community
> to make sure that agents and services are robust in case of dependent
> services (database, rabbitmq
> ) failures, to make sure they reconnect and continue when those become
> available.
>
> On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers <aspiers at suse.com> wrote:
>
>> Kosnik, Lubosz <lubosz.kosnik at intel.com> 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 checking external and internal
>> connectivity. To detect split brain. Elect master, even keepalived was
>> running but Peacemaker was automatically killing all services and moving
>> FIP.
>> > Assaf - is there any change in this implementation in RDO? Or you’re
>> still doing everything outside of Neutron?
>> >
>> > Because if RDO success is build on Peacemaker it means that yes,
>> Neutron needs some solution which will be available for more than RH
>> deployments.
>>
>> Agreed.
>>
>> With help from others, I have started an analysis of some of the
>> different approaches to L3 HA:
>>
>>     https://ethercalc.openstack.org/Pike-Neutron-L3-HA
>>
>> (although I take responsibility for all mistakes ;-)
>>
>

Did you test with this patch https://review.openstack.org/#/c/255237/  ? It
was merged in newton cycle.
With this patch, HA+L2pop doesn't depend on control plane during fail over,
hence failover should be faster(same as without l2pop).


>
>> It would be great if someone from RH or RDO could provide information
>> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
>> keepalived works - if so, I volunteer to:
>>
>>   - help populate column E of the above sheet so that we can
>>     understand if there are still remaining gaps in the solution, and
>>
>>   - document it (e.g. in the HA guide).  Even if this only ended up
>>     being considered as a shorter-term solution, I think it's still
>>     worth documenting so that it's another option available to
>>     everyone.
>>
>> Thanks!
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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/20170223/53876d5a/attachment.html>