Current Series Release Notes

25.0.0

Upgrade Notes

  • All wsgi application implementations using eventlet for heat-api, heat-api-cfn and heat-all are removed as a precusror to dropping eventlet usage from heat.

  • Integration with monasca has been removed because the monasca project was retired. Because of the removal, the following resource types are no longer supported and now hidden.

    • OS::Monasca::AlarmDefinition

    • OS::Monasca::Notifications

    Also, the options in [clients_monasca] section have been removed.

  • Support for Python 3.9 has been removed. Now Python 3.10 is the minimum version supported.

Deprecation Notes

  • The heat-api console script and the heat-api-cfn console script, which are used to launch standalone api services, have been deprecated and will be removed in a future release. It is now highly recommended to Use the wsgi scripts (or wsgi applications directly) instead.

  • The legacy engine has been deprecated and convergence engine will be the only supported engine. Due to this deprecation, the following options have been deprecated.

    • [DEFAULT] convergence_engine

    • [DEFAULT] enable_stack_abandon

    • [DEFAULT] enable_stack_adopt

  • The root_app_factory composite factory has been deprecated, because it is equivalent the urlmap factory from paste. Replace usage in api-paste.ini in case the file is modified to use customized pipelines.

Bug Fixes

  • Enable the creation of an OS::Neutron::VPNService resource, and an OS::Neutron::IPsecSiteConnection resource that depends on it, within the same stack.

24.0.0

New Features

  • A new module, heat.wsgi, has been added as a place to gather WSGI application objects. This is intended to ease deployment by providing a consistent location for these objects. For example, if using uWSGI then instead of:

    [uwsgi]
wsgi-file = /bin/heat-api

    You can now use:

    [uwsgi]
module = heat.wsgi.api:application

    This also simplifies deployment with other WSGI servers that expect module paths such as gunicorn.

  • The new resources, OS::Octavia::AvailabilityZoneProfile and OS::Octavia::AvailabilityZone, are added. These resource types allow an operator to create Octavia availabilityzone profile and availabilityzone. A created OS::Octavia::AvailabilityZone resource can be referred by the availability_zone property of OS::Octavia::LoadBalancer resources.

  • Added the tenant_id property to the following resources. This property allows admin users to create these resources in specific tenants.

    • OS::Neutron::ProviderNet

    • OS::Neutron::Router

  • Added attributes property to resource type OS::Designate::Zone. It can be any key:value pairs of information about this zone including the pool where the user wants to place the zone used by the scheduler.

  • The new [DEFAULT] max_cinder_api_microversion option has been added. This option overrides the maximum API microversion supported by Cinder, which is detected automatically by default.

  • The OS::Cinder::Volume resource type now supports extending volumes in use. Note that this requires that Cinder supports API microversion 3.42 or later.

Upgrade Notes

  • OS::Manila::Share attribute export_locations will now be a list of export paths

Deprecation Notes

  • The heat-all console script has been deprecated and will be removed in a future release.

Bug Fixes

  • Fixed the consistent type mismatch error caused by creating or updating a stack with files stored in OpenStack Swift containers, using the files_container parameter. Now file content is always decoded and can be used as a string value.

  • Changed the type of the following parameters from integer to string, to correctly parse micro versions with trailing zero (e.g. 2.20).

    • [DEFAULT] max_nova_api_microversion

    • [DEFAULT] max_ironic_api_microversion

  • OS::Manila::Share attribute export_locations will now be a list of export paths

23.0.0

New Features

  • Add to OS::Designate::RecordSet new types: CAA, CERT, NAPTR.

  • Fixed the OS::Heat::UpdateWaitConditionHandle resource type, which caused stack update to fail consistently.

  • The following parameters have been added, to define timeout in internal HTTP requests.

    • [DEFAULT] metadata_put_timeout

    • [DEFAULT] template_fetch_timeout

    • [ec2authtoken] timeout

Upgrade Notes

  • Python 3.8 support was dropped. The minimum version of Python now supported is Python 3.9.

  • Integration with Sahara has been removed because the Sahara project has been retired. Because of the removal, the following resource types are no longer supported and now hidden.

    • OS::Senlin::Cluster

    • OS::Senlin::Node

    • OS::Senlin::Policy

    • OS::Senlin::Profile

    • OS::Senlin::Receiver

    Also, the options in [clients_sahara] section have been removed.

  • Default value of the [DEFAULT] hidden_stack_tags option has been updated and now stacks with the data-processing-cluster tag is not hidden by default.

  • Integration with Senlin has been removed because the Senlin project has been retired. Because of the removal, the following resource types are no longer supported and now hidden.

    • OS::Senlin::Cluster

    • OS::Senlin::Node

    • OS::Senlin::Policy

    • OS::Senlin::Profile

    • OS::Senlin::Receiver

    Also, the options in [clients_senlin] section have been removed.

22.0.0

New Features

  • Add OS::Aodh::PrometheusAlarm resource to enable autoscaling with Prometheus instead of Gnocchi.

  • Heat now supports limiting the number of software configs, software deployments, stack snapshots which users can create, by the following config options. These limits are not enforced for users with admin role.

    • [DEFAULT] max_software_configis_per_tenant

    • [DEFAULT] max_software_deployments_per_tenant

    • [DEFAULT] max_snapshots_per_stack

Upgrade Notes

  • The heat-manage migrate_properties_data command is deprecated and is now a no-op. It will be removed in a future release.

  • Now heat enables the API policies (RBAC) new defaults and scope by default. The default value of config options [oslo_policy] enforce_scope and [oslo_policy] enforce_new_defaults have been changed from False to True.

  • The OS::Glance::Image type is now hidden.

  • Now the following limits are enforced by default unless a request user has an admin role.

    • Maximum number of software configs per project is 4096

    • Maximum number of software deployments per project is 4096

    • Maximum number of stack snapshots per tenant is 32

    Set the following options in case the limits should be increased. Limits can be disabled by setting -1 to these options.

    • [DEFAULT] max_software_configis_per_tenant

    • [DEFAULT] max_software_deployments_per_tenant

    • [DEFAULT] max_snapshots_per_stack

  • The [DEFAULT] onready option has been removed. This option has had no effect.

Deprecation Notes

  • The following resources have been deprecated because Monasca, Sahara and Senlin were marked inactive and will not get deliverables for the 2024.1 release. These resources will be removed in 23.0.0 release.

    • OS::Monasca::*

    • OS::Sahara::*

    • OS::Senlin::*

21.0.0

New Features

  • Heat policies have been modified to isolate the system and project-level APIs policy. Because of this change, system users will not be allowed to perform any operations on project-level resources.

Upgrade Notes

  • The following resource types are now hidden. Neutron LBaaS v2 was already retired thus these resource types can no longer be used.

    • OS::Neutron::LBaaS::LoadBalancer

    • OS::Neutron::LBaaS::Listener

    • OS::Neutron::LBaaS::Pool

    • OS::Neutron::LBaaS::PoolMember

    • OS::Neutron::LBaaS::HealthMonitor

    • OS::Neutron::LBaaS::L7Policy

    • OS::Neutron::LBaaS::L7Rule

  • The database migration engine has changed from sqlalchemy-migrate to alembic. For most deployments, this should have minimal to no impact and the switch should be mostly transparent. The main user-facing impact is the change in schema versioning. While sqlalchemy-migrate used a linear, integer-based versioning scheme, which required placeholder migrations to allow for potential migration backports, alembic uses a distributed version control-like schema where a migration’s ancestor is encoded in the file and branches are possible. The alembic migration files, therefore, use an arbitrary UUID-like naming scheme and the heat-manage db_sync command now expects such a version when manually specifying the version that should be applied. For example:

    $ heat-manage db_sync c6214ca60943

    Attempting to specify an sqlalchemy-migrate-based version will result in an error.

20.0.0.0rc1

Bug Fixes

  • Honor hidden parameter in get stack environment API. Now values passed to hidden parameters are replaced by ‘**’, similarly to the other APIs such as show stack details API.