On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo < majop...@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. > > On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers <aspi...@suse.com> wrote: > >> Kosnik, Lubosz <lubosz.kos...@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 ;-) >> > Did you test with this patch https://review.openstack.org/#/c/255237/ ? It was merged in newton cycle. With this patch, HA+L2pop doesn't depend on control plane during fail over, hence failover should be faster(same as without l2pop). > >> 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-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > >
__________________________________________________________________________ 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