2025.1 Series Release Notes¶
20.1.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.
20.1.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.
20.0.0¶
New Features¶
The action std.mistral_http will now retrun an error if the HTTP request fails. Previously the task would still go into the RUNNING state and wait to be completed by the external resource.
Deprecation Notes¶
The coordination service inside mistral has been used only to list the mistral services list behind the endpoint
v2/services. This feature is not enabled by default and needs a specificcoordinatorbackend_urlconfiguration to be set for mistral to answer the services list correctly. Coordination rely on thetoozproject and, depending on the driver in use, may need eventlet monkeypatching. Because we want to get rid of all eventlet code inside mistral, thev2/servicesendpoint is now deprecated and all coordination code will be dropped in the next cycle.
The kombu RPC driver in mistral is now deprecated and will be removed in the next cycle. In the effort to keep mistral up and running, we decided to drop experimental features like kombu RPC driver, which does not bring anything more than the default oslo.messaging driver.