Bug 1649363 - [RFE] backport customize haproxy options on a per-service basis LP:1755711
Summary: [RFE] backport customize haproxy options on a per-service basis LP:1755711
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: puppet-tripleo
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: zstream
: 10.0 (Newton)
Assignee: Michele Baldessari
QA Contact: pkomarov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-13 13:32 UTC by Eduard Barrera
Modified: 2019-12-29 21:41 UTC (History)
15 users (show)

Fixed In Version: puppet-tripleo-5.6.8-20.el7ost
Doc Type: Enhancement
Doc Text:
This update lets the operator specify custom timeouts for each haproxy back end via special hiera keys: ExtraConfig: tripleo::haproxy::cinder::options: 'timeout client': '90m' 'timeout server': '90m' With this support an operator can specify custom options for each haproxy back end.
Clone Of:
Environment:
Last Closed: 2019-01-16 17:09:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1755711 0 None None None 2018-11-13 13:32:10 UTC
Red Hat Product Errata RHBA-2019:0055 0 None None None 2019-01-16 17:09:52 UTC

Description Eduard Barrera 2018-11-13 13:32:11 UTC
Description of problem:

Can we have [1] backported to OSP10 ?

"""
It is currently not possible to customize haproxy on a per service basis.
There are situations where it would be advantageous to let
an operator specify custom per-service options.
One such use case seen in the wild is to extend the timeout of the cinder
because due to the specific storage backend these cinder operations
sometimes take a bit longer. Letting the user tweak the
haproxy_default_timeout is likely not what we want as for the case
above we only want to tweak a single service.
"""

[1]https://bugs.launchpad.net/tripleo/+bug/1755711

Comment 2 Artem Hrechanychenko 2018-11-13 16:42:37 UTC
upstream bz filled and fixed by bandini, so moving from df to pidone as well

Comment 4 paldeala 2018-11-21 18:06:56 UTC
Hi, any updates?

Thanks

Comment 17 pkomarov 2018-12-16 15:41:16 UTC
Verified, 

[stack@undercloud-0 ~]$ cat core_puddle_version 
2018-12-13.1[stack@undercloud-0 ~]$ 

#redeploy with extra configs for custom haproxy params: 

[stack@undercloud-0 ~]$ diff overcloud_deploy.sh overcloud_deploy.shorg

< -e /home/stack/custom_haproxy_timeout.yaml

[stack@undercloud-0 ~]$ cat /home/stack/custom_haproxy_timeout.yaml
ExtraConfig:
  tripleo::haproxy::cinder::options:
    "timeout client": '88m'


 Stack overcloud CREATE_COMPLETE 

Overcloud Endpoint: http://10.0.0.105:5000/v2.0
Overcloud Deployed


[stack@undercloud-0 ~]$ ansible controller -b -mshell -a'grep 88 /etc/haproxy/haproxy.cfg'
 [WARNING]: Found both group and host with same name: undercloud

controller-0 | SUCCESS | rc=0 >>
  timeout client 88m
  timeout server 88m

controller-1 | SUCCESS | rc=0 >>
  timeout client 88m
  timeout server 88m

Comment 19 errata-xmlrpc 2019-01-16 17:09:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0055


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