Queens Series Release Notes

13.0.3-9

Upgrade Notes

  • publicize_image policy now has the same name both for image create and edit features and corresponds to the same one in Glance. If you changed the policy name manually to get feature working you have to rollback your changes before Horizon update.

Security Issues

  • An open redirect has been fixed, that could redirect users to arbitrary addresses from certain views by specifying a “next” parameter in the URL. Now the redirect will only work if the target URL is in the same domain, and uses the same protocol.

Bug Fixes

  • [bug:1859041] image:publicize_image policy is renamed to publicize_image to be the same as Glance has.

13.0.3

Bug Fixes

  • Fix an error on image description field when it is changed in the Angularized panel [:bug: 1779879]

  • [bug:1840465] Fixed a bug where listing security groups did not work if one or more security groups had no rules in them.

13.0.0

New Features

  • [blueprint:neutron-trunk-ui] Neutron trunk feature is now supported. It is supported in both the project and admin dashboards. The panel will be displayed if Neutron API extension ‘trunk’ is available. It displays information about trunks. The details page for each trunk also shows information about subports of that trunk.

  • [blueprint ng-keypairs] AngularJS-based Key Pairs panel is added. The features in the legacy panel are fully implemented. The Key Pairs panel now may be configured to use either the legacy or AngularJS-based codes. The ANGULAR_FEATURES setting now allows for a key_pairs_panel. If set to True, then the AngularJS-Based Key Pairs panel will be used, while the Django version will be used if set to False. Default value for key_pairs_panel is True.

  • Added the way to specify an interface when attaching it to an instance. It can be specified by a network and a fixed IP address (optional) or a port.

  • Cinder API v3 is used by default now. It was introduced in Mitaka release and has all features from API v2.

  • The keystone v3 API now becomes the default keystone API version.

  • Floating IP addresses have a description field that is now exposed in the dashboard. It is also possible to set the description when allocating a floating IP.

  • The policy framework in horizon now supports policy directories per service. This corresponds to policy_dirs configuration option from “oslo.policy” library. The new setting POLICY_DIRS was introduced. The setting allows to define multiple policy directories per service. For example, it is useful for a case where multiple projects provide policy files like neutron stadium projects. For detail, see the horizon Setting Reference.

  • Support security groups association per network port for operators and users. Note that the current implementation only supports to edit security groups of neutron port from the port tables in the network detail page (Further improvement is planned).

Known Issues

  • [bug:1746706] When reloading or opening Angular-based detail page directly, the navigation menu and breadcrumb list are not recovered properly and the first panel is focused. [bug:1746709] when we try to open non-existing Angular-based detail page, “Not Found” (404) page is not shown. A blank page only with the navigation menu will be shown.

Upgrade Notes

  • If your deployment doesn’t have Cinder API v3 endpoint like volumev3 you should create new endpoint or use Cinder API v2 via setting OPENSTACK_API_VERSIONS[‘volume’] = 2 in your OpenStack Dashboard (Horizon) configuration file.

  • The default keystone API vesion is switch to v3. If you still use the keystone v2.0 API by default, you need to configure OPENSTACK_API_VERSIONS and OPENSTACK_KEYSTONE_URL to point to the keystone v2.0 API.

  • Heat dashboard is now split out into a separate project heat-dashboard. All new features and maintenances are provided from the new project from now on. The new project provides all features available in Horizon in the past release. To continue to use heat dashboard, install heat-dashboard and set up the horizon plugin configuration file in enabled directory. For more information, see heat-dashboard documentation https://docs.openstack.org/heat-dashboard/latest/.

  • [blueprint:merge-openstack-auth] django_openstack_auth was merged into the main horizon repository. Ensure to uninstall django-openstack-auth python package BEFORE upgrading horizon to Queens.

Deprecation Notes

  • Remove formerly deprecated initScope() function for Angularized actions. Instead use initAction() and get scope from second parameter of perform() function.

Bug Fixes

  • [bug:1337473] The default quotas of neutron resource for a new project are no longer got from the quotas of the current project. Neutron did not provide a way to retrieve the default quotas and horizon used the quotas of the current project as the default quotas for a new project as a workaround. Neutron implemented an API to retrieve default quotas since newton and horizon now consumes it.

  • [bug:1681627] A problem that Angular-based detail page (ngdetail page) cannot be reloaded or opened via direct URL has been fixed. Note that there are some known issues described in the Known Issues section.

  • A new setting OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES was introduced to control whether IP addresses of servers are retrieved from neutron in the project instance table. This setting was introduces to mitigate a performance issue in large deployments and setting this to False skips the query to neutron. Deployments without floating IP support can set this setting to False for better performance. For more detail, see [bug:1722417].

Other Notes

  • The Queens release of horizon depends on Django 1.8 to 1.11, but Django 1.8 to 1.10 support will be dropped in the next release (Rocky).

  • (For Horizon plugin developers) The AVAIL_CHANGED event of transfer table is removed. It is superseded by event TABLES_CHANGED. The name of AVAIL_CHANGED was misleading because it implicitly and uncontrollably updated the allocated table too. The new event allows independent updates to all four tables. We believe it is safe to remove AVAIL_CHANGED without deprecation because its implementation contained a bug that must have been discovered before if anybody had used it. Anyway possible out-of-tree plugin maintainers are recommended to consume the new event even if your plugins relied on the buggy behavior of AVAIL_CHANGED.