Stein Series Release Notes


New Features

  • Added a new config option server_keystone_endpoint_type to specify the keystone authentication endpoint (public/internal/admin) to pass into cloud-init data. If left unset the original behavior should remain unchanged.

    This feature allows the deployer to unambiguously specify the keystone endpoint passed to user provisioned servers, and is particularly useful where the deployment network architecture requires the heat service to interact with the internal endpoint, but user provisioned servers only have access to the external network.

    For more information see

Bug Fixes

  • Erroneously, availability_zone for host aggregate resource types was considered mandatory in heat templates.

    Behaviour has been adjusted to bring this in line with the CLI and GUI, in which it is optional.



Added new tool heat-status upgrade check.

New Features

  • Add multiple OpenStack orchestration support - User can now use OS::Heat::Stack to create stack in another OpenStack cloud. Must provide properties credential_secret_id in context. Remote stack resource will get authentication information from cloud credential to refresh context before calling stack create.

  • A new OS::Blazar::Host resource is added to manage compute hosts for the lease/reservation in OpenStack.

  • A new OS::Blazar::Lease resource is added to manage reservations for specific type/amount of cloud resources in OpenStack.

  • Add rbac_policy and subnetpool support for OS::Neutron::Quota resource.

  • Add UDP to supported protocols for Octavia.

  • A new OS::Neutron::TaaS::TapService resource is added to support a Tap Service in the Neutron Tap-as-a-service plugin.

  • A new OS::Neutron::TaaS::TapFlow resource is added to support a Tap Flow in the Neutron Tap-as-a-service plugin.

  • Add a new OS::Glance::WebImage resource supporting the web-download import of Glance v2.

  • New framework for heat-status upgrade check command is added. This framework allows adding various checks which can be run before a Heat upgrade to ensure if the upgrade can be performed safely.

  • New resource OS::Neutron::L2GatewayConnection to allow management of Neutron Layer2 Gateway Connection. This resource provides capability to connect a Neutron network to a Layer2 Gateway. The resource depends on the Neutron l2-gateway extension.

  • New resource OS::Neutron::L2Gateway to allow management of Neutron Layer2 Gateway. This resource provides life-cycle management of layer2 gateway instances. The resource depends on the Neutron l2-gateway extension.

  • Add tags support for ProviderNet resource

  • Add ca_cert and insecure properties for OS::Heat::Stack resource type. The ca_cert is the contents of a CA Certificate file that can be used to verify a remote cloud or region’s server certificate. insecure is boolean option, CA cert will be use if we didn’t setup insecure flag.

Upgrade Notes

  • The distribution name has been changed from “heat” to “openstack-heat” so that we can publish packages to This may have an effect on downstream package builds if they rely on asking setuptools to determine the package name.

  • New config max_nova_api_microversion to set the maximum nova API microversion for nova client plugin. If``max_nova_api_microversion`` is set, any nova features supported with microversion number above max_nova_api_microversion will not be available.

  • Operator can now use new CLI tool heat-status upgrade check to check if Heat deployment can be safely upgraded from N-1 to N release.

Deprecation Notes

  • personality property of OS::Nova::Server is now deprecated, please use user_data or metadata instead. If that property really required, use config max_nova_api_microversion to set the maximum nova API microversion <2.57 for nova client plugin to support personality property.

Bug Fixes

  • We now allowed global admins to operate software deployment and software config resources from other projects.

  • Heat can now perform a stack update to roll back to a previous version of a resource after a previous attempt to create a replacement for it failed (provided that convergence is enabled). This allows the user to recover a stack where a resource has been inadvertantly replaced with a definition than can never succeed because it conflicts with the original. Previously this required automatic rollback to be enabled, or the user had to update the stack with a non-conflicting definition before rolling back to the original.