Open Stack

On Wed, Feb 22, 2017 at 1:40 PM, Miguel Angel Ajo Pelayo
<majopela at redhat.com> wrote:
> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> architecture
> in the case of HA, pacemaker is not taking care of those anymore since the
> HA-NG implementation.
>
> We let systemd take care to restart the services that die, and we worked
> with the community
> to make sure that agents and services are robust in case of dependent
> services (database, rabbitmq
> ) failures, to make sure they reconnect and continue when those become
> available.

Thanks Miguel, I added a little bit of info the spreadsheet as well.

>
> On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers <aspiers at suse.com> wrote:
>>
>> Kosnik, Lubosz <lubosz.kosnik at intel.com> wrote:
>> > 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.
>> > 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.
>> > Assaf - is there any change in this implementation in RDO? Or you’re
>> > still doing everything outside of Neutron?
>> >
>> > 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.
>>
>> Agreed.
>>
>> With help from others, I have started an analysis of some of the
>> different approaches to L3 HA:
>>
>>     https://ethercalc.openstack.org/Pike-Neutron-L3-HA
>>
>> (although I take responsibility for all mistakes ;-)
>>
>> It would be great if someone from RH or RDO could provide information
>> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
>> keepalived works - if so, I volunteer to:
>>
>>   - help populate column E of the above sheet so that we can
>>     understand if there are still remaining gaps in the solution, and
>>
>>   - document it (e.g. in the HA guide).  Even if this only ended up
>>     being considered as a shorter-term solution, I think it's still
>>     worth documenting so that it's another option available to
>>     everyone.
>>
>> Thanks!
>>
>> __________________________________________________________________________
>> 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
>