2023.2 Series Release Notes¶
21.0.0-6¶
New Features¶
Fixed the
OS::Heat::UpdateWaitConditionHandle
resource type, which caused stack update to fail consistently.
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 resources 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 a arbitrary UUID-like naming scheme and the
heat-manage db_sync
command now expects such an 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.