Use frontend/backend sections in HAProxy config

Now that HAProxy configurations can leverage
frontend/backend statements [1], make this the new default
for this cycle, as it allows more complex proxying
scenario that are a prerequisite for optimizing the routing
of API calls in a HA control plane.

[1] Ieb36f90c6709934aa3aa6668d3929bff872c30f5

Change-Id: Ic25c258895872210e7cf2d760769b492842f0048
Related-Bug: #1941617

deployment/haproxy/haproxy-container-puppet.yaml

@@ -41,6 +41,11 @@ parameters:
     default: local0
     description: Syslog facility HAProxy will use for its logs
     type: string
+  HAProxyConfigBackendSyntax:
+    default: true
+    description: Generate a config that uses Frontend and Backend
+                 sections rather than the old Listen sections
+    type: boolean
   SSLCertificate:
     default: ''
     description: >
@@ -181,6 +186,7 @@ outputs:
               if:
                 - {get_param: EnableInternalTLS}
                 - {get_param: InternalTLSCAFile}
+            haproxy_backend_syntax: {get_param: HAProxyConfigBackendSyntax}
           - get_attr: [HAProxyPublicTLS, role_data, config_settings]
           - get_attr: [HAProxyInternalTLS, role_data, config_settings]
       # BEGIN DOCKER SETTINGS

releasenotes/notes/haproxy-frontend-backend-b253d26eeadbfb6b.yaml

@@ -0,0 +1,8 @@
+---
+features:
+  - |
+    A new Heat parameter HAProxyConfigBackendSyntax news drives the generation
+    of HAproxy configuration. Prior to that, every service was mapped to
+    a 'listen' section in the configuration. Now a service definition is
+    split in two sections 'frontend' and 'backend', which allow for more
+    complex proxying configurations.