Zed Series Release Notes

18.0.0.0b1-214

New Features

  • The blazar dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_blazar_ui: True
    
  • The cloudkitty dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_cloudkitty_ui: True
    
  • The os_horizon role now supports distribution of user custom themes. Deployers can use the new key theme_src_archive of horizon_custom_themes dictionary to provide absolute path to the archived theme. Only .tar.gz, .tgz, .zip, .tar.bz, .tar.bz2, .tbz, .tbz2 archives are supported. Structure inside archive should be as a standard theme, without any leading folders.

  • The service setup in keystone for horizon will now be executed through delegation to the horizon_service_setup_host which, by default, is localhost (the deploy host). Deployers can opt to rather change this to the utility container by implementing the following override in user_variables.yml.

    horizon_service_setup_host: "{{ groups['utility_all'][0] }}"
    
  • Added variable horizon_bind_address which defines IP address where Apache will listen on horizon_listen_ports

  • Added variable horizon_policy_overrides which allows to customize horizon specific policies. As we don’t want to carry and maintain horizon policies with OSA, they’re retrieved from horizon hosts and adjusted in-place, which means that they won’t rollback in case you just remove override. horizon_policy_overrides has also non-standart format, as it’s nested dictionary, where 1st level key represents service which policy needs to be overriden, and it’s value is normal policy override format.

  • Horizon now has the ability to run directly from uWSGI. To support this feature the new Boolean variable horizon_use_uwsgi has been added. The new variable, when set to true, will omit the apache2 install process and instead run horizon from a uWSGI process leveraging a systemd service file.

  • Implemented horizon WEBSSO auto redirects. Following new variables were added to manage redirects configuration:

    • horizon_websso_default_redirect

    • horizon_websso_default_redirect_region

    • horizon_websso_default_redirect_logout

  • Horizon has, since OSA’s inception, been deployed with HTTPS access enabled, and has had no way to turn it off. Some use-cases may want to access via HTTP instead, so this patch enables the following.

    • Listen via HTTPS on a load balancer, but via HTTP on the horizon host and have the load balancer forward the correct headers. It will do this by default in the integrated build due to the presence of the load balancer, so the current behaviour is retained.

    • Enable HTTPS on the horizon host without a load balancer. This is the role’s default behaviour which matches what it always has been.

    • Disable HTTPS entirely by setting haproxy_ssl: no (which will also disable https on haproxy. This setting is inherited by the new horizon_enable_ssl variable by default. This is a new option.

  • Add the possibility to disable openrc v2 download in the dashboard. new var horizon_show_keystone_v2_rc can be set to False to remove the entry for the openrc v2 download.

  • The masakari dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_masakari_ui: True
    
  • The murano dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_murano_ui: True
    
  • VPNaaS dashboard is again available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_neutron_vpnaas: True
    
  • The role now supports using the distribution packages for the OpenStack services instead of the pip ones. This feature is disabled by default and can be enabled by simply setting the nova_install_method variable to distro.

  • Added variables horizon_session_engine and horizon_session_caches which can be used to configure horizon session engine and a backend for it.

  • The tacker dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_tacker_ui: True
    
  • The watcher dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_watcher_ui: True
    
  • The zun dashboard is available in Horizon. Deployers can enable the panel by setting the following Ansible variable:

    horizon_enable_zun_ui: True
    

Upgrade Notes

  • horizon_listen_ports variable was transformed to the dictionary with required keys http and https to have effect not only for apache ports.conf file, but also for the virtual host.

  • SESSION_ENGINE has been changed to memcached by default. So that horizon do not require it’s own database for storing session information anymore. horizon_galera_* variables has no effect now.

Deprecation Notes

  • The variable horizon_requires_pip_packages is no longer required and has therefore been removed.

  • Variable horizon_enable_neutron_lbaas has been removed because of global neutron lbaas retirement process. This means that horizon neutron-lbaas-ui plugin won’t be installed.

  • The variable ‘horizon_ssl_cipher_suite’ is deprecated in favour of ‘horizon_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 TLS1.2. 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 horizon_ssl_protocol variable.

Bug Fixes

  • Change of horizon_webroot variable is now respected and will be reflected in Apache configuration to serve static files and define wsgi path accordingly.

Other Notes

  • When the option horizon_use_uwsgi is enabled, operators need to be aware that not all horizon capabilities will be present. The minimal uSGI process is just that, minimal, and not full featured. If the deployment requires full featured capabilities, the apache based deployment should remain enabled.