I'm all for it!
Another benefit is better coverage for the standalone CI job(s), when it
will (hopefully) become a mandatory dependency for overcloud multinode
jobs.
On 7/16/18 12:49 PM, Sergii Golovatiuk wrote:
Hi,
On Fri, Jul 13, 2018 at 9:11 PM, Juan Antonio Osorio
<[email protected]> 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, <[email protected]> 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
