Current Series Release Notes

20.0.0-25

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 we stop provide any heartbeat for long while. And no method to clean services status. For services that run on containers (like in K8s), The list of UP services statuses just piling up. Add new cmd designate-manage service clean to delect and clean any service that fail to provide heartbeat within double heartbeat interval time. CONF.heartbeat_emitter.heartbeat_interval default to 10 seconds.

  • Fixed collection links for 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 config default_limit_v2 that would cause some clients to enter an endless loop.

    See bug #2106112.

  • If primary zone is updated, Designate does two actions simultaneously: 1) sends NOTIFY to secondary DNS server 2) updates its backend Notification is significantly faster then backend update. So secondary DNS server gets previous zone version (SOA). Now it’s fixed. Designate sends NOTIFY after 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

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