Stein Series Release Notes

8.0.1-5

Bug Fixes

• Adding distributed locking to central

  The central service was not using a global lock which can lead to a race condition in a high availability setup leading to missing recordsets in the DNS backend. This release includes a partial backport of a distributed locking mechanism to central.

  Fixes bug 1871332

8.0.1

New Features

• Adds a new option for pools using the pdns4 backend: tsigkey_name. This allows deployers to specify a tsig key that is installed in powerdns to use for AFXR requests. This key name is the name used to create the key in powerdns, not the Designate UUID based ID for the key.

  Note

  This is only available in the 4.2.x versions (and above) of pdns.

8.0.0

New Features

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

• Designate can verify validity of the project id when setting quotas for it. This feature is enabled by setting a new configuration option [service:api]quotas_verify_project_id to True (default is False for backward compatibility).

• A new designate-status upgrade check command has been added which can be used to validate a deployment before starting services with new code. See the documentation for details: https://docs.openstack.org/designate/latest/cli/designate-status.html

Upgrade Notes

• New installs will now have pool manager disabled by default and will use the worker and producer services. To continue to use pool manager set enabled=False in the [service:worker] of your config.

• Custom notification handlers that created unmanaged records will need to be updated, as we no longer support the creation of unmanaged records using the sink.

  See designate/notification_handler/base.py for more details.

Other Notes

• To allow for python3.7 support, the designate-worker service was changed from a ThreadPoolExecutor to a GreenThreadPoolExecutor. This should no impact for most deployments, but in some cases it may cause performance degredation. In these cases, tuning [service:worker].workers and [service:worker].threads alleviate the issues.