Bug 1572808 - osp13 deployment with opendaylight fails due to haproxy not being able to check OpenDaylight port 8081
Summary: osp13 deployment with opendaylight fails due to haproxy not being able to che...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: opendaylight
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: beta
: ---
Assignee: Tim Rozet
QA Contact: Itzik Brown
URL:
Whiteboard:
Depends On: 1572807
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-27 23:31 UTC by Waldemar Znoinski
Modified: 2018-10-25 05:24 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
N/A
Last Closed: 2018-04-30 13:55:17 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Waldemar Znoinski 2018-04-27 23:31:24 UTC
Description of problem:
the full story is described in https://bugzilla.redhat.com/show_bug.cgi?id=1572807 as it's most likely problem with tripleo-puppet code

this bug here is show we have a blocker bug existing and if not possible to fix in puppet tripleo then action may be needed in opendaylight

Version-Release number of selected component (if applicable):
osp13, puddle 2018-04-24.3

How reproducible:
100%

Steps to Reproduce:
1. deploy osp13 with opendaylight and above puddle
2.
3.

Actual results:
deployment fails, haproxy shows 'NO SRV' when checks odl's port 8081

Expected results:
deployment to succeed

Additional info:

Comment 2 Waldemar Znoinski 2018-04-30 10:11:30 UTC
it looks like after https://github.com/openstack/puppet-tripleo/commit/8f9a98888efdb75fd877b24c946214d60fdfacec which brought the default values (including httpck) is causing it - thanks Tim!

Comment 3 Janki 2018-04-30 13:25:54 UTC
Possible solution can be to replace "source" with "roundrobin" as listen_options.

listen_options  => {
        'balance' => 'roundrobin',
      },

so the whole ODL config section would look like

  if $opendaylight {
    ::tripleo::haproxy::endpoint { 'opendaylight':
      internal_ip     => unique([hiera('opendaylight_api_vip', $controller_virtual_ip), $controller_virtual_ip]),
      service_port    => $ports[opendaylight_api_port],
      ip_addresses    => hiera('opendaylight_api_node_ips', $controller_hosts_real),
      server_names    => hiera('opendaylight_api_node_names', $controller_hosts_names_real),
      mode            => 'http',
      member_options  => union($haproxy_member_options, $internal_tls_member_options),
      service_network => $opendaylight_network,
      listen_options  => {
        'balance' => 'roundrobin',
      },
    }

    ::tripleo::haproxy::endpoint { 'opendaylight_ws':
      internal_ip     => unique([hiera('opendaylight_api_vip', $controller_virtual_ip), $controller_virtual_ip]),
      service_port    => $ports[opendaylight_ws_port],
      ip_addresses    => hiera('opendaylight_api_node_ips', $controller_hosts_real),
      server_names    => hiera('opendaylight_api_node_names', $controller_hosts_names_real),
      mode            => 'http',
      service_network => $opendaylight_network,
      listen_options  => {
        # NOTE(jaosorior): Websockets have more overhead in establishing
        # connections than regular HTTP connections. Also, since it begins
        # as an HTTP connection and then "upgrades" to a TCP connection, some
        # timeouts get overridden by others at certain times of the connection.
        # The following values were taken from the following site:
        # http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/
        'timeout' => ['connect 5s', 'client 25s', 'server 25s', 'tunnel 3600s'],
        'balance' => 'roundrobin',
      },
    }


Note You need to log in before you can comment on or make changes to this bug.