Designate

No recovery of zones after a backend bind9 disaster

Bug #1934139 reported by Fontenay Tony
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Designate
New
Undecided
Unassigned

Bug Description

Hello,

I don't know if this problem is bug or a configuration problem.
After shutting down and removing bind9 volumes, Designate worker and producer do not recover zones that have not been modified. To recover the zones, an update of the zone is mandatory.
With the pool-manager it was possible to force a synchronization by doing a designate sync-all, is it still possible to force designate producer to synchronize the zones?

Revision history for this message
Michael Johnson (johnsom) wrote :

I think running an "designate-manage pool update" (You should make sure you have a valid pools.yaml to pass in or in your /etc) will trigger an update the zones in the pools.

Revision history for this message
Michael Johnson (johnsom) wrote :

Reference: https://review.opendev.org/c/openstack/designate/+/731603

Revision history for this message
Fontenay Tony (weezhard) wrote :

Yes, I did an "designate-manage pool update" and validated the loading with an "designate-manage pool show_config". The problem is not with the masters but with the Slavs who are not repopulated. On the other hand, if we carry out an update on the zone then it is well recreated with a transfer. Is it possible to transfer areas without updating ?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.