<div dir="auto"> Sounds good to me. Even if pacemaker is heavier, less options and consistency is better.<div dir="auto"><br></div><div dir="auto">Greetings from Mexico :D</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 13 Jul 2018, 13:33 Emilien Macchi, <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Greetings,<div><br></div><div>We have been supporting both Keepalived and Pacemaker to handle VIP management.</div><div>Keepalived is actually the tool used by the undercloud when SSL is enabled (for SSL termination).</div><div>While Pacemaker is used on the overcloud to handle VIPs but also services HA.</div><div><br></div><div>I see some benefits at removing support for keepalived and deploying Pacemaker by default:</div><div>- pacemaker can be deployed on one node (we actually do it in CI), so can be deployed on the undercloud to handle VIPs and manage HA as well.</div><div>- it'll allow to extend undercloud & standalone use cases to support multinode one day, with HA and SSL, like we already have on the overcloud.</div><div>- it removes the complexity of managing two tools so we'll potentially removing code in TripleO.</div><div>- of course since pacemaker features from overcloud would be usable in standalone environment, but also on the undercloud.</div><div><br></div><div>There is probably some downside, the first one is I think Keepalived is much more lightweight than Pacemaker, we probably need to run some benchmark here and make sure we don't make the undercloud heavier than it is now.<br clear="all"><div><br></div><div>I went ahead and created this blueprint for Stein:</div><div><a href="https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default" target="_blank" rel="noreferrer">https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default</a><br></div><div>I also plan to prototype some basic code soon and provide an upgrade path if we accept this blueprint.</div><div><br></div><div>This is something I would like to discuss here and at the PTG, feel free to bring questions/concerns,</div><div>Thanks!</div>-- <br><div dir="ltr" class="m_1712327727548548242gmail-m_-6329195582394880091gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>