2025.2 Series Release Notes

21.0.0

New Features

  • SVCB and HTTPS recordset type have been added. All users should be able to use this type from the API and openstack client. This can be disabled (like other record types) by setting the [DEFAULT].supported-record-type config variable in all designate services.

  • A new module, designate.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/designate-api-wsgi

    You can now use:

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

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

Known Issues

  • This doesn’t support the arbitrary keys “keyNNNNN” format.

Upgrade Notes

  • The WSGI script designate-api-wsgi has been removed. Deployment tooling should instead reference the Python module path for the wsgi module in Designate, designate.wsgi.api:application if their chosen WSGI server supports this (gunicorn, uWSGI, etc.) or implement a .wsgi script themselves if not (mod_wsgi).

Bug Fixes

  • A fix was added to handle SOA email addresses that include dots correctly.

  • New cmd designate-manage service clean. Previously Designate service always stuck in UP even though we stopped providing any heartbeat for a long while. And no method to clean services status. For services that run on containers (like in K8s), the list of UP services statuses is just piling up. Add new cmd designate-manage service clean to detect and clean any service that fails to provide a heartbeat within a double heartbeat interval time. CONF.heartbeat_emitter.heartbeat_interval defaults to 10 seconds.

  • Fixed collection links for the floating IP API endpoint returning a next key pointing to itself when the exact amount of floating IPs in a project was the same as the config default_limit_v2 that would cause some clients to enter an endless loop.

    See bug #2106112.

  • If the primary zone is updated, Designate does two actions simultaneously: 1) sends NOTIFY to the secondary DNS server 2) updates its backend. Notification is significantly faster than a backend update. So the secondary DNS server gets the previous zone version (SOA). Now it’s fixed. Designate sends NOTIFY after a successful backend update.

Other Notes

  • BIND9 older than 9.21.8 does not use named Service Parameter Keys (SvcParamKeys) by default. BIND9 9.21.8 or newer must be used to support the SVCB and HTTPS recordset types.

20.0.0

Bug Fixes

  • The refresh secondary zone task was broken. It failed all the time. If MDNS didn’t get NOTIFY from the master server, the secondary zone didn’t get updates. Now it’s fixed.