Releasenotes¶

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project will adhere to Semantic Versioning.

We use towncrier for the generation of our release notes file.

Information about unreleased changes can be found here.

For changes before winter 2025/26 you only can check for changes using e.g. git log --no-merges which will give you a rough overview of earlier changes.

release-20251211¶

Fix for CVE-2025-14758: MariaDB with IPv6 enable TLS for replication

We got reported in issue #631 that at IPv6 setups MariaDB doesn’t use TLS for replications. As we change from non TLS to TLS now, new MariaDB Pods can’t connect to the existing ones. A manual downscale and upscale of the Statefulset is needed.

release-20251128¶

Upgrade RabbitMQ clusters to 4.2

The new release will automatically upgrade all RabbitMQ clusters to version 4.1 first and to version 4.2 directly afterwards. During the upgrade, Yaook will ensure that all stable features are enabled and run a pre check job that fails if a deprecated feature is still in use.

We recommend to check the state of RabbitMQ before the rollout is done.
1. To see if all stable features are enabled, run:
```
rabbitmqctl list_feature_flags | grep disabled
```
If the upgrade from 3.12 to 3.13 was done correctly or the server was created with version 3.13, this should only list the following:

khepri_db disabled

If more disabled features are listed, these need to be enabled, but if you do this, the quorum queues can stop working after the next rolling restart in some cases. To enable the feature flags, run:
```
rabbitmqctl enable_feature_flag all
```
Afterwards trigger a rolling restart and check if the queues are still functional by checking the metric rabbitmq_queue_not_running_count or the rabbitmq-exporter logs. If the queues are broken, you can either recreate them or recreate the entire RabbitMQ cluster (which is a lot faster for a high number of queues).
1. To check the use of deprecated features, run:
```
rabbitmq-diagnostics check_if_any_deprecated_features_are_used
```
Some clusters might detect the usage of the feature transient_nonexcl_queues. If this is the case, ensure that all rabbit_transient_quorum_queue: false overrides are removed. Afterwards delete all affected queues:
```
rabbitmqctl list_queues name durable | grep "false$" | cut -f 1 | xargs -i rabbitmqctl delete_queue
```
Afterwards, restart the OpenStack services to ensure they are recreated. Again, if there are a lot of queue it might be faster to rebuild the RabbitMQ cluster.

WARNING! For the Octavia AMQPServer, the pre check job will fail during the upgrade from 4.1 to 4.2 because by default, rabbit_transient_quorum_queue: false is still set. #635 This will be fixed in the future, but until then you should manually override the setting:
```
kubectl -n "${YAOOK_OP_NAMESPACE}" patch octaviadeployment <octavia_name> --type=json \
-p="[{\"op\":\"replace\",\"path\":\"/spec/octaviaConfig/oslo_messaging_rabbit\",\"value\":{"rabbit_transient_quorum_queue": true}}]"
```
Afterwards recreate the queues or the Octavia AMQPServer as mentioned before.

release-20230914¶

OVN upgrade 22.12.0 to 23.3.1 The upgrade is done automatically with a workflow added some releases ago, but you can also jump directly to this release.

release-20230504¶

Changed¶

We introduced network.yaook.cloud/neutron-bgp-agent as label to schedule neutron-ovn-agents separately from neutron network nodes(network.yaook.cloud/neutron-ovn-agent). ovn-bgp-agents will be deleted if no action is taken: The node label needs to be added, where you want to run bgp agents before updating.