Hi, On Fri, Jul 13, 2018 at 9:11 PM, Juan Antonio Osorio <jaosor...@gmail.com> wrote: > Sounds good to me. Even if pacemaker is heavier, less options and > consistency is better. > > Greetings from Mexico :D
Greetings from PoznaĆ :D > > On Fri, 13 Jul 2018, 13:33 Emilien Macchi, <emil...@redhat.com> wrote: >> >> Greetings, >> >> We have been supporting both Keepalived and Pacemaker to handle VIP >> management. This is really good initiative which supports the main idea of 'simplicity'. >> Keepalived is actually the tool used by the undercloud when SSL is enabled >> (for SSL termination). >> While Pacemaker is used on the overcloud to handle VIPs but also services >> HA. >> >> I see some benefits at removing support for keepalived and deploying >> Pacemaker by default: >> - 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. Additionally, undercloud services may be done HA on 3 nodes if/when it's really required. >> - 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. >> - it removes the complexity of managing two tools so we'll potentially >> removing code in TripleO. ++ >> - of course since pacemaker features from overcloud would be usable in >> standalone environment, but also on the undercloud. The same OCF scripts will be used for undercloud and overcloud. >> >> 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. From other perspective operator need to learn/support 2 tools. >> >> I went ahead and created this blueprint for Stein: >> >> https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default >> I also plan to prototype some basic code soon and provide an upgrade path >> if we accept this blueprint. I would like to participate in this initiative as I found it very valuable. >> >> This is something I would like to discuss here and at the PTG, feel free >> to bring questions/concerns, >> Thanks! >> -- >> Emilien Macchi >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best Regards, Sergii Golovatiuk __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev