<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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-HOEnZb"><div class="gmail-h5"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>Kosnik, Lubosz <<a href="mailto:lubosz.kosnik@intel.com" target="_blank">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.or<wbr>g/Pike-Neutron-L3-HA</a><br>
<br>
(although I take responsibility for all mistakes ;-)<br></blockquote></div></div></div></div></blockquote><div><br><br></div><div>Did you test with this patch <a href="https://review.openstack.org/#/c/255237/">https://review.openstack.org/#/c/255237/</a> ? It was merged in newton cycle.<br></div><div>With this patch, HA+L2pop doesn't depend on control plane during fail over, hence failover should be faster(same as without l2pop).<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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="gmail-m_853549516644621576HOEnZb"><div class="gmail-m_853549516644621576h5"><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div></div>