Cannot customize haproxy options on a per-service basis

[Michele Baldessari]

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.

[Michele Baldessari (michele)]

https://review.openstack.org/552819

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/552819
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=ce4576375df1e49442e87ce26b8be436bd00b899
Submitter: Zuul
Branch: master

commit ce4576375df1e49442e87ce26b8be436bd00b899
Author: Michele Baldessari <email address hidden>
Date: Wed Mar 14 08:31:40 2018 +0100

    Allow custom per-service listen_options for haproxy

    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.

    We explored another approach to fix this by adding a bunch of
    <service>_options class parameters in the tripleo::haproxy class but it
    made it extremely bloated and confusing, so we opted for this approach
    which is much less invasive both code-wise and complexity-wise

    Tested by deploying with:
    ExtraConfig:
      tripleo::haproxy::cinder::options:
        "timeout client": '90m'
        'timeout server': '90m'

    And observing the following cinder haproxy stanza:
    listen cinder
      bind 10.0.0.4:8776 transparent
      bind 172.16.2.9:8776 transparent
      mode http
      http-request set-header X-Forwarded-Proto https if { ssl_fc }
      http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
      option httpchk
      option httplog
      timeout client 90m
      timeout server 90m
      server overcloud-controller-0.internalapi.localdomain 172.16.2.7:8776 check fall 5 inter 2000 rise 2
      server overcloud-controller-1.internalapi.localdomain 172.16.2.16:8776 check fall 5 inter 2000 rise 2
      server overcloud-controller-2.internalapi.localdomain 172.16.2.13:8776 check fall 5 inter 2000 rise 2

    Closes-Bug: #1755711

    Change-Id: Icb7f026190b310d34c47dc059e2fdb22031b0963

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/554153

[OpenStack Infra (hudson-openstack)]

Change abandoned by Emilien Macchi (<email address hidden>) on branch: stable/queens
Review: https://review.openstack.org/554153
Reason: clear up the gate to merge CI blockers, I'll restore the patches.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/554153
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=ea2ce7da21e57124129e1f60ac0cff0d0f6ed9f9
Submitter: Zuul
Branch: stable/queens

commit ea2ce7da21e57124129e1f60ac0cff0d0f6ed9f9
Author: Michele Baldessari <email address hidden>
Date: Wed Mar 14 08:31:40 2018 +0100

    Allow custom per-service listen_options for haproxy

    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.

    We explored another approach to fix this by adding a bunch of
    <service>_options class parameters in the tripleo::haproxy class but it
    made it extremely bloated and confusing, so we opted for this approach
    which is much less invasive both code-wise and complexity-wise

    Tested by deploying with:
    ExtraConfig:
      tripleo::haproxy::cinder::options:
        "timeout client": '90m'
        'timeout server': '90m'

    And observing the following cinder haproxy stanza:
    listen cinder
      bind 10.0.0.4:8776 transparent
      bind 172.16.2.9:8776 transparent
      mode http
      http-request set-header X-Forwarded-Proto https if { ssl_fc }
      http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
      option httpchk
      option httplog
      timeout client 90m
      timeout server 90m
      server overcloud-controller-0.internalapi.localdomain 172.16.2.7:8776 check fall 5 inter 2000 rise 2
      server overcloud-controller-1.internalapi.localdomain 172.16.2.16:8776 check fall 5 inter 2000 rise 2
      server overcloud-controller-2.internalapi.localdomain 172.16.2.13:8776 check fall 5 inter 2000 rise 2

    Closes-Bug: #1755711

    Change-Id: Icb7f026190b310d34c47dc059e2fdb22031b0963
    (cherry picked from commit ce4576375df1e49442e87ce26b8be436bd00b899)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/puppet-tripleo 8.3.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/puppet-tripleo 9.0.0 release.