Current Series Release Notes

18.0.0.0b1-202

New Features

  • HAProxy services that use backend nodes that are not in the Ansible inventory can now have the backend_port specified in the list, along with name or ip_addr settings. This allow to have the service bound to different port on different backend servers.

  • Added variables haproxy_bind_external_lb_vip_interface and haproxy_bind_internal_lb_vip_interface that allows deployer to bind haproxy on the specific interface only.

  • Added variable haproxy_tls_vip_binds that allows to fully override haproxy bindings, that are generated by the role if some assumptions are not valid for some scenarios. It is list of mappings, that include address and interface. Interface key is optional and can be ommited.

  • Multiple HAProxy nodes can now be deployed in an HA configuration with keepalived and LetsEncrypt certificates. Certbot can be treated as a backend service for haproxy and acme-challenge requests from LetsEncrypt can be directed to whichever HAProxy server is running a certificate renewal. New variables are defined for frontend ACLs and options to be passed to Certbot which enable this new feature, but the majority of the required configuration is done via the existing HAProxy service setup. An example is provided in the documentation.

  • A new variable haproxy_stick_table can be defined to apply a customised stick-table to all backends on the loadbalancer. In addition, haproxy_stick_table can be set in each service definition to have a customised stick-table for a particular backend.

  • A new key haproxy_default_backend can be defined for each service configured in the haproxy loadbalancer. Configuring this variable writes a value for the default_backend directive into the config for the service frontend. It can be useful to provide a specific default backend as a fall-through option when other backends are selected using ACLs, and to also allow the name of the default backend to be different from haproxy_service_name.

  • Added new keys haproxy_frontend_h2 and haproxy_backend_h2 per service definition to enable HTTP/2 for a specified service.

    This also add new variables to control default behavoir for frontends and backends:

    • haproxy_frontend_h2: true

    • haproxy_backend_h2: false

    Please mention, that double stack of HTTP/1.1 and HTTP/2 is only available for TLS protected frontends. In case frontend is just TCP haproxy_frontend_h2 will be ignored.

    At the same time haproxy_backend_h2 will be respected regardless of TLS/plain TCP configuration.

  • It is now possible to have a service which only have a frontend. by using haproxy_frontend_only inside your service.

  • Add the possibility to have a haproxy_frontend_raw entry to control haproxy config for the frontend, the entry will be literally copied in to the service. You can set a list under the key haproxy_frontend_raw

  • Added new variable haproxy_hatop_install, that allows to conditionally enable or disable hatop installation.

  • A new key haproxy_map_entries is now able to be configured for each haproxy service definition to allow arbitrary entries to be placed in any number of haproxy map files which may then be referenced in other directives in the haproxy config file such as use_backend or http-request. The complete map files are constructed from the fragments defined across all the service definitions and are assembled into a complete map file in alphanumeric sort order, or optionally with a user defined ordering.

  • Added variable haproxy_ssl_letsencrypt_certbot_challenge which is default to http-01. As for now really tested in only http-01 but we keep door open for adding support for more challanges, like dns-01. For http-01 all required arguments are passed, but oth other challanges you might want to use haproxy_ssl_letsencrypt_setup_extra_params to pass missing arguments.

  • haproxy_pki_create_certificates was implemented. It allows users to explicitly disable certificates generation with PKI role but keep using it for certificates distribution.

  • HAProxy services can now override the path of the certificate with haproxy_ssl_path if set under the service definition.

  • If Horizon dashboard of OSA installation has a public FQDN, is it now possible to use LetsEncrypt certification service. Certificate will be generated within HAProxy installation and a cron entry to renew the certificate daily will be setup. Note that there is no certificate distribution implementation at this time, so this will only work for a single haproxy-server environment.

  • Added new variable haproxy_stick_table_enabled to haproxy_service_configs, that allows you to conditionally enable or disable the default stick-table.

  • The HAProxy role now supports TLS v1.3 by default, alongside TLS v1.2.

Upgrade Notes

  • A default stick-table was previously applied to all backends by default but did not have any specific purpose. This is now removed, and the variable haproxy_stick_table should be used to supply a list of config lines to be applied to each backend to control stick-table functionality.

  • HTTP/2 is enabled by default for frontends that are covered with TLS. You can disable this behaviour by setting haproxy_frontend_h2: false

  • Variable haproxy_hatop_downloader has been removed, Deployers supposed to use haproxy_hatop_download_url override if needed to install in deployments with limited internet connection.

  • HAProxy haproxy_whitelist_networks key inside haproxy_service_configs dictionary has been replaced with haproxy_allowlist_networks.

  • There’s no need in providing neither http-01-address nor http-01-port options with haproxy_ssl_letsencrypt_setup_extra_params, as they are now configured with corresponding variables haproxy_ssl_letsencrypt_certbot_bind_address and haproxy_ssl_letsencrypt_certbot_backend_port

  • If you have defined haproxy_tuning_params in your deployment, make sure that before upgrade all keys are valid haproxy options. For example, instead of chksize: 16384 you should set tune.chksize: 16384. Otherwise invalid config will be generated and haproxy will fail on startup. No upgrade scripts are provided for this change as well as no backwards compatability.

Deprecation Notes

  • The following variables have been deprecated and will have no effect:

    • haproxy_ssl_cert_path

    • haproxy_ssl_key

    • haproxy_ssl_pem

    • haproxy_ssl_ca_cert

    These variables were responsible for the path haproxy looked for certificates on the destination hosts.

    Variables were replaced in favor of haproxy_ssl_cert_path since the exact path to certificates will be dynamically set based on the VIP that is used for the frontend

  • Certbot-auto is deprecated since 2020. It was removed from haproxy_server role.

  • haproxy_service_configs format was simplified. Now it’s just a list of dicts. Usage of service key in haproxy_service_configs elements is deprecated and will be removed in 2023.2 release.

  • The variable ‘haproxy_ssl_cipher_suite’ is deprecated in favour of ‘haproxy_ssl_cipher_suite_tls12’ which will continue to manage configuration of ciphers for TLS v1.2 and earlier.

Security Issues

  • The default TLS version has been set to force-tlsv12. This only allows version 1.2 of the protocol to be used when terminating or creating TLS connections. You can change the value with the haproxy_ssl_bind_options variable.

Bug Fixes

  • Fixed inconsistency in haproxy_frontend_raw key naming between documentation and service template. Previously, template generation was expecting haproxy_raw instead of the haproxy_frontend_raw.

  • Variables haproxy_fall and haproxy_rise are now respected again and will be used for defining amount of checks before haproxy will mark backend as UP or DOWN. Keys backend_rise and haproxy_fall that are set inside service definition are still respected and will have prescedence over global ones.

  • By default we increase tune.maxrewrite as otherwise while using CSP headers, their size could exceed allowed buffer. Also deployers can override this value if needed.

Other Notes

  • Restriction on parameters that can be passed to haproxy_tuning_params has been released. This means, that any tuning parameter can be passed in key/value format.