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:
it looks like after https://github.com/openstack/puppet-tripleo/commit/8f9a98888efdb75fd877b24c946214d60fdfacec which brought the default values (including httpck) is causing it - thanks Tim!
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', }, }