Back to bug 1644883

Who When What Removed Added
Red Hat Bugzilla Rules Engine 2018-10-31 19:39:46 UTC Target Release 13.0 (Queens) ---
Carlos Goncalves 2018-10-31 19:41:23 UTC Status NEW ASSIGNED
Target Release --- 14.0 (Rocky)
Blocks 1581337
Depends On 1581337
Assignee amuller nmagnezi
Target Milestone --- beta
Red Hat Bugzilla Rules Engine 2018-10-31 19:41:30 UTC Target Release 14.0 (Rocky) ---
Red Hat Bugzilla Rules Engine 2018-11-01 11:26:49 UTC Target Release --- 14.0 (Rocky)
Scott Lewis 2019-01-11 14:13:02 UTC Target Milestone beta ---
Red Hat Bugzilla Rules Engine 2019-01-11 14:13:04 UTC Target Release 14.0 (Rocky) ---
Carlos Goncalves 2019-01-14 11:19:12 UTC Target Release --- 14.0 (Rocky)
Target Milestone --- z1
Flags needinfo?(nmagnezi)
PnT Account Manager 2019-02-14 15:04:27 UTC CC nyechiel
Carlos Goncalves 2019-03-05 16:08:19 UTC Target Milestone z1 z2
Nir Magnezi 2019-04-16 11:39:11 UTC Blocks 1700359
Nir Magnezi 2019-04-16 13:44:00 UTC Status ASSIGNED ON_DEV
Target Milestone z2 z3
Flags needinfo?(nmagnezi)
Nir Magnezi 2019-05-08 09:23:03 UTC Status ON_DEV MODIFIED
Fixed In Version openstack-octavia-3.0.2-0.20181219195056.ec4c88e.el7ost
Doc Text In order to use the PING type health monitor, the HAProxy (default software we use in our driver for network load balancing) version must be at least 1.6. Any use of an older HAProxy version makes the health-check be TCP connect without the user's knowledge.

The upstream community fixed that by adding a check in the code, that determine the HAProxy version that is in use and acts accordingly:
If HAProxy version 1.6 or later, we can use PING.
Otherwise, we keep using TCP connect (in the absence of any other solution for those haproxy versions, it is better to do so rather than breaking it altogether).

The problem we have in OSP13 GA is that we ship HAProxy as a part of RHEL channels, which uses an old version of HAProxy. Thus, when OSP13 users configure the PING type health monitor, they will get TCP connect instead.
Doc Type If docs needed, set a value Known Issue
errata-xmlrpc 2019-05-29 21:36:22 UTC Status MODIFIED ON_QA
Jon Schlueter 2019-05-30 11:32:10 UTC Status ON_QA MODIFIED
errata-xmlrpc 2019-05-30 18:46:08 UTC Status MODIFIED ON_QA
Steve Linabery 2019-05-31 20:01:52 UTC Status ON_QA MODIFIED
Steve Linabery 2019-06-01 20:01:46 UTC Status MODIFIED ON_QA
Roee Agiman 2019-06-10 09:08:30 UTC CC ragiman
QA Contact astafeye bbonguar
Roger Heslop 2019-06-11 18:16:32 UTC CC rheslop
Doc Text In order to use the PING type health monitor, the HAProxy (default software we use in our driver for network load balancing) version must be at least 1.6. Any use of an older HAProxy version makes the health-check be TCP connect without the user's knowledge.

The upstream community fixed that by adding a check in the code, that determine the HAProxy version that is in use and acts accordingly:
If HAProxy version 1.6 or later, we can use PING.
Otherwise, we keep using TCP connect (in the absence of any other solution for those haproxy versions, it is better to do so rather than breaking it altogether).

The problem we have in OSP13 GA is that we ship HAProxy as a part of RHEL channels, which uses an old version of HAProxy. Thus, when OSP13 users configure the PING type health monitor, they will get TCP connect instead.
Previously, when the `PING` type health monitor was configured, HAProxy would silently use TCP connect instead. This is because Red Hat OpenStack Platform uses an older version of HAProxy that does not support external monitors. The setting `allow_ping_health_monitors` is now set to `False` by default.
Bruna Bonguardo 2019-06-13 15:49:07 UTC Depends On 1717144
Bruna Bonguardo 2019-06-24 10:22:45 UTC Status ON_QA VERIFIED
errata-xmlrpc 2019-07-02 15:48:03 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2019-07-02 19:47:40 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2019-07-02 19:47:40 UTC
errata-xmlrpc 2019-07-02 19:47:55 UTC Link ID Red Hat Product Errata RHBA-2019:1680
Nir Magnezi 2019-09-10 14:12:36 UTC CC nmagnezi
Carlos Goncalves 2020-02-04 13:59:40 UTC Blocks 1798064

Back to bug 1644883