Open Stack

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 ;-)
>
> 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: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/cd58de92/attachment.html>