Stein Series Release Notes¶
8.0.1-5¶
バグ修正¶
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¶
新機能¶
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.注釈
This is only available in the 4.2.x versions (and above) of pdns.
8.0.0¶
新機能¶
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
アップグレード時の注意¶
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.
その他の注意点¶
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.