[Bug 1879798] Please test proposed package

[Corey Bryant]

Hello Zachary, or anyone else affected,

Accepted designate into stein-proposed. The package will build now and
be available in the Ubuntu Cloud Archive in a few hours, and then in the
-proposed repository.

Please help us by testing this new package. To enable the -proposed
repository:

  sudo add-apt-repository cloud-archive:stein-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-stein-needed to verification-stein-done. If it does
not fix the bug for you, please add a comment stating that, and change
the tag to verification-stein-failed. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance!

** Changed in: cloud-archive/stein
       Status: New => Fix Committed

** Tags added: verification-stein-needed

** Changed in: cloud-archive/train
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1879798

Title:
  designate-manage pool update doesn't reflects targets master dns
  servers into zones.

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive stein series:
  Fix Committed
Status in Ubuntu Cloud Archive train series:
  Fix Committed
Status in Ubuntu Cloud Archive ussuri series:
  Fix Committed
Status in Ubuntu Cloud Archive victoria series:
  Fix Released
Status in Ubuntu Cloud Archive wallaby series:
  Fix Released
Status in Ubuntu Cloud Archive xena series:
  Fix Released
Status in Designate:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in designate source package in Focal:
  Fix Committed

Bug description:
  [Environment]

  Ubuntu + Ussuri

  [Description]

  If running designate-manage pool update with new targets, those targets
  gets properly updated in the pool target masters list, but those aren't
  reflected into the zones that belongs to this pool, therefore, the masters
  associated to that zones aren't updated causing failures as the expressed
  in the Further Information section.

  designate-manager pool update should offer an option to update the zones
  associated to the pools with the new target masters and be able to apply
  these changes into existing zones.

  For the case of the bind9 backend the current workaround is to manually
  run the rndc modzone command with the new masters, but that's not suitable
  for large installations with multiple zones and pools.

  
  [Further information]

  We have a designate/designate-bind setup. We migrated designate units
  to different machines, replacing 3 designate units with 3 new units.
  However, this caused issues with existing zones, including creating
  new recordsets for these zones. The zone would result in having an
  ERROR status and a CREATE action.

  Looking at the designate bind units, we see that designate is
  attempting to run:

  'addzone $zone { type slave; masters {$new_designate_ips port 5354;};
  file "slave.$zone.$hash"; };'

  This addzone fails due to the zone already existing. However, we found
  that the zone configuration (using 'rndc showzone $zone' from
  designate-bind unit) still had the old designate ips for its masters.
  There are also logs in /var/log/syslog like the following:

  May 20 06:27:10 juju-c27f05-15-lxd-1 named[72648]: transfer of '$zone'
  from $old_designate_ip#5354: failed to connect: host unreachable

  We were able to resolve this issue by modifying the zone config on all
  designate-bind units:

  juju run -a designate-bind -- rndc modzone $zone '{ type slave; file
  "slave.$zone.$hash"; masters { $new_designate_ip_1 port 5354;
  $new_designate_ip_2 port 5354; $new_designate_ip_3 port 5354; }; };'

  After modifying the zone, the recordset creations completed and
  resolved almost immediately.

  Would this be something the charm could do in an automated way when
  masters are removed/replaced, or is there a better way of fixing the
  zone configurations? For these designate migrations, we will have to
  enumerate over every zone to fix their configurations.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1879798/+subscriptions