Back to bug 1371948

Who When What Removed Added
Charlie Llewellyn 2016-08-31 13:54:38 UTC CC cllewellyn
Steve Relf 2016-08-31 13:55:18 UTC CC srelf
Assaf Muller 2016-08-31 13:57:13 UTC Target Release --- 8.0 (Liberty)
Assignee amuller jschwarz
RHEL Program Management 2016-08-31 14:34:17 UTC Keywords ZStream
Darryl Weaver 2016-08-31 14:53:08 UTC CC darryl
John Schwarz 2016-09-04 06:20:29 UTC Status NEW ASSIGNED
John Schwarz 2016-09-08 14:55:35 UTC CC rohara
Flags needinfo?(rohara)
John Schwarz 2016-09-08 14:56:14 UTC CC majopela
Ryan O'Hara 2016-09-08 16:01:13 UTC Flags needinfo?(rohara)
John Schwarz 2016-09-25 11:45:55 UTC Flags needinfo?(amuller)
Paul Needle 2016-11-24 11:40:48 UTC CC smulholland
Priority unspecified urgent
CC pneedle
Severity high urgent
Paul Needle 2016-11-24 11:47:42 UTC Blocks 1398286
John Schwarz 2016-12-05 17:27:30 UTC Link ID OpenStack gerrit 407099
Assaf Muller 2016-12-09 21:25:48 UTC Flags needinfo?(amuller)
Paul Needle 2016-12-15 12:20:57 UTC Flags needinfo?(jschwarz)
John Schwarz 2016-12-15 12:23:29 UTC Flags needinfo?(jschwarz)
John Schwarz 2017-01-04 13:28:53 UTC Status ASSIGNED POST
John Schwarz 2017-01-31 16:57:53 UTC Status POST ON_DEV
Ihar Hrachyshka 2017-03-27 17:52:19 UTC CC ihrachys
Assignee jschwarz ihrachys
Ihar Hrachyshka 2017-03-27 17:53:09 UTC Blocks 1436359
Ihar Hrachyshka 2017-03-27 17:54:41 UTC Blocks 1436363
Ihar Hrachyshka 2017-03-29 03:58:41 UTC Status ON_DEV POST
Ihar Hrachyshka 2017-04-05 19:35:49 UTC Status POST MODIFIED
Fixed In Version openstack-neutron-7.2.0-7.el7ost
Doc Text Cause: the default L3 HA implementation, keepalived, sometimes flips master router instance to backup if it receives multiple SIGHUP signals in quick succession.

Consequence: HA master router sometimes flipped to backup, disrupting L3 connectivity until the previous backup keepalived instance takes over.

Fix: to work around keepalived behavior, Neutron L3 agent now throttles SIGHUP signals sent to keepalived to make sure keepalived has enough time to reload configuration without being disrupted with failovers.

Result: L3 connectivity implemented via HA routers is not disrupted on router updates in quick succession (floating IP updates and such).
Doc Type If docs needed, set a value Bug Fix
Mike Burns 2017-05-22 19:56:07 UTC Keywords Triaged
errata-xmlrpc 2017-05-25 21:02:26 UTC Status MODIFIED ON_QA
Ofer Blaut 2017-05-29 06:42:52 UTC CC oblaut
QA Contact tfreger gcheresh
GenadiC 2017-06-06 08:45:43 UTC Status ON_QA VERIFIED
Martin Lopes 2017-06-15 01:36:52 UTC CC mlopes
Doc Text Cause: the default L3 HA implementation, keepalived, sometimes flips master router instance to backup if it receives multiple SIGHUP signals in quick succession.

Consequence: HA master router sometimes flipped to backup, disrupting L3 connectivity until the previous backup keepalived instance takes over.

Fix: to work around keepalived behavior, Neutron L3 agent now throttles SIGHUP signals sent to keepalived to make sure keepalived has enough time to reload configuration without being disrupted with failovers.

Result: L3 connectivity implemented via HA routers is not disrupted on router updates in quick succession (floating IP updates and such).
Previously, the default L3 HA implementation (keepalived) sometimes flipped the master router instance to `backup` if it received multiple SIGHUP signals in quick succession. Consequently, L3 connectivity was disrupted until the previous backup keepalived instance took over.
With this update, to work around this keepalived behavior, the neutron L3 agent now throttles SIGHUP signals sent to keepalived to make sure keepalived has enough time to reload configuration without being disrupted by failovers.
As a result, L3 connectivity implemented using HA routers is not disrupted after router updates arriving in quick succession (for example, with floating IP updates).
errata-xmlrpc 2017-06-15 04:10:10 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2017-06-20 12:56:17 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2017-06-20 08:56:17 UTC
Paul Needle 2017-07-06 14:39:29 UTC Link ID Red Hat Knowledge Base (Solution) 3106671

Back to bug 1371948