Bug 1649363

Summary:	[RFE] backport customize haproxy options on a per-service basis LP:1755711
Product:	Red Hat OpenStack	Reporter:	Eduard Barrera <ebarrera>
Component:	puppet-tripleo	Assignee:	Michele Baldessari <michele>
Status:	CLOSED ERRATA	QA Contact:	pkomarov
Severity:	high	Docs Contact:
Priority:	high
Version:	10.0 (Newton)	CC:	aherr, ahrechan, bperkins, chjones, dcadzow, jamsmith, jjoyce, jschluet, michele, mkrcmari, paldeala, pkomarov, slinaber, tvignaud, tvvcox
Target Milestone:	zstream	Keywords:	FeatureBackport, FutureFeature, Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-01-16 17:09:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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