2025.2 Series Release Notes¶
21.0.0-11¶
Security Issues¶
Added a new
cron_triggers:publicizepolicy (admin_only) and enforcement on create when scope is public. Previously, the cron trigger POST endpoint hardcoded the scope toprivateand ignored the scope field from the request body, so cron triggers could never be created as public. The scope field is now properly passed through to the database.
Added a new
dynamic_actions:publicizepolicy (admin_only) and enforcement on both create and update operations when scope is public. Previously, the dynamic actions POST endpoint did not persist the scope field and neither POST nor PUT enforced a publicize policy, allowing any user with create or update access to make dynamic actions public.
Added a new
environments:publicizepolicy (admin_only) and enforcement on both create and update operations when scope is public. Previously, the environment POST endpoint did not accept the scope field in the request body and neither POST nor PUT enforced a publicize policy, allowing any user with update access to make environments public.
Added a new
workbooks:publicizepolicy (admin_only) and enforcement on both create and update operations when scope is public. Previously, any project owner could make workbooks public as there was no publicize policy check on the workbook endpoints.
All
code_sourcesanddynamic_actionsAPI policies are now restricted to admin users only (admin_only). Previously, these policies defaulted toadmin_or_owner, allowing any project owner to create, read, update, and delete code sources and dynamic actions. Operators who need to restore the previous behavior can override the relevant policies in theirpolicy.yaml.
The
publicizepolicy for workflows, actions, and event triggers is now restricted to admin users only (admin_only). Previously, any project owner could make these resources public. A newcode_sources:publicizepolicy has also been added with the sameadmin_onlydefault, and publicize checks are now enforced on both create and update operations for code sources and event triggers where they were previously missing.
21.0.0¶
New Features¶
Added mutually exclusive config options
[action_providers]/allowlistand[action_providers]/denylistthat can be used to filter what action providers is loaded.
Added mutually exclusive config options
[legacy_action_provider]/allowlistand[legacy_action_provider]/denylistthat can be used to filter what actions is loaded by the legacy action provider.
Upgrade Notes¶
Support for Python 3.8 and 3.9 has been dropped.
The
oslo_rpc_executoroption is removed. If you were explicitly settingoslo_rpc_executor = threadingin your configuration, you can safely remove this setting as threading is now the only supported executor type.
Deprecation Notes¶
Deprecate the
api_workersoption for mistral-api. This option was used to spawn multiple workers when using oslo.service wsgi server. Since we moved to cheroot, this is not possible anymore. If you want to use more than one process to handle Mistral API requests, you should consider using mistral-wsgi-api behind a wsgi server.
Kombu RPC driver is now deleted from mistral RPC drivers. Only oslo messaging driver is supported.
Bug Fixes¶
The Mistral API is now served by
cheroot.wsgi.Serverinstead of the deprecatedoslo_service.wsgi/ eventlet stack. Behaviour and CLI commands are unchanged.
Other Notes¶
Adding a new wsgi entrypoint to allow using it within WSGI servers (like uWSGI) using
mistral.wsgi:application.Note that this is the only way to start more than one mistral API worker.
Also adding two environment variables
MISTRAL_CONFIG_DIRandMISTRAL_CONFIG_FILEto allow setting config-dir and config-file when using the new wsgi entrypoint.
The /v2/services endpoint in mistral is now removed. This endpoint was using tooz.coordination which we decided to get rid of in the previous release. That endpoint was introduced in the past to help administrator know which services were running but we believe this is not widely used and can easily be replaced by external tooling.