Stein Series Release Notes¶
8.0.1-5¶
Corrections de bugs¶
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¶
Nouvelles fonctionnalités¶
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¶
Nouvelles fonctionnalités¶
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
toTrue
(default isFalse
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
Notes de mises à jours¶
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.
Autres 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.