Open Stack

Hi,

On Fri, Jul 13, 2018 at 9:11 PM, Juan Antonio Osorio
<jaosorior at 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, <emilien at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Best Regards,
Sergii Golovatiuk