<div dir="ltr">I have updated the spreadsheet. In the case of RH/RDO we're using the same architecture<div>in the case of HA, pacemaker is not taking care of those anymore since the HA-NG implementation.</div><div><br></div><div>We let systemd take care to restart the services that die, and we worked with the community</div><div>to make sure that agents and services are robust in case of dependent services (database, rabbitmq</div><div>) failures, to make sure they reconnect and continue when those become available.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers <span dir="ltr"><<a href="mailto:aspiers@suse.com" target="_blank">aspiers@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Kosnik, Lubosz <<a href="mailto:lubosz.kosnik@intel.com">lubosz.kosnik@intel.com</a>> wrote:<br>
> 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.<br>
> 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.<br>
> Assaf - is there any change in this implementation in RDO? Or you’re still doing everything outside of Neutron?<br>
><br>
> 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.<br>
<br>
</span>Agreed.<br>
<br>
With help from others, I have started an analysis of some of the<br>
different approaches to L3 HA:<br>
<br>
    <a href="https://ethercalc.openstack.org/Pike-Neutron-L3-HA" rel="noreferrer" target="_blank">https://ethercalc.openstack.<wbr>org/Pike-Neutron-L3-HA</a><br>
<br>
(although I take responsibility for all mistakes ;-)<br>
<br>
It would be great if someone from RH or RDO could provide information<br>
on how this RDO (and/or RH OSP?) solution based on Pacemaker +<br>
keepalived works - if so, I volunteer to:<br>
<br>
  - help populate column E of the above sheet so that we can<br>
    understand if there are still remaining gaps in the solution, and<br>
<br>
  - document it (e.g. in the HA guide).  Even if this only ended up<br>
    being considered as a shorter-term solution, I think it's still<br>
    worth documenting so that it's another option available to<br>
    everyone.<br>
<br>
Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>