Zed Series Release Notes

18.0.0.0b1-168

New Features

  • 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.

  • 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.

  • 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.

  • 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.

  • 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

  • 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.