yahoo-eng-team team mailing list archive

[Jay Jahns <2067183@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

When we were trying to register an instance via agent to an external
cloud backup service, the instance returned a FQDN not consistent with
what its floating IP was set to, and not what the service needs to
return a successful registration.

We are using Designate and OVN/ML2 on 2023.2 in a production
environment.

The dns_domain value of the project network was configured with the zone
that was created in Designate, thus allowing floating IP addresses to
create records accordingly.

However, the dns_domain of the network is not used in dns_assignment,
nor is it used as the search domain, as it uses the conf value alone.

There was an attempt made to fix the DHCP side of this:
https://bugs.launchpad.net/neutron/+bug/1774710

It was reverted in this change:
https://bugs.launchpad.net/neutron/+bug/1826419

Adjusting the ML2 extension for DNS can result in the necessary
dns_assignment changes, which in-turn, update the lease in dnsmasq;
however, it does not incorporate the search domain update. Functionally,
this one change seems to have fixed the registration problems we were
experiencing, but I can see where the search domain could also have
impacts.

Other use cases include externally managed automation, such as
AWX/Ansible, which may rely on the FQDN being returned back by the
instance in order to function correctly.

Considering this is in the critical path for us to have functional, I
believe that it merits discussion for change.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2067183

Title:
  Properly Use Network's DNS Domain in Assignment and DHCP

Status in neutron:
  New

Bug description:
  When we were trying to register an instance via agent to an external
  cloud backup service, the instance returned a FQDN not consistent with
  what its floating IP was set to, and not what the service needs to
  return a successful registration.

  We are using Designate and OVN/ML2 on 2023.2 in a production
  environment.

  The dns_domain value of the project network was configured with the
  zone that was created in Designate, thus allowing floating IP
  addresses to create records accordingly.

  However, the dns_domain of the network is not used in dns_assignment,
  nor is it used as the search domain, as it uses the conf value alone.

  There was an attempt made to fix the DHCP side of this:
  https://bugs.launchpad.net/neutron/+bug/1774710

  It was reverted in this change:
  https://bugs.launchpad.net/neutron/+bug/1826419

  Adjusting the ML2 extension for DNS can result in the necessary
  dns_assignment changes, which in-turn, update the lease in dnsmasq;
  however, it does not incorporate the search domain update.
  Functionally, this one change seems to have fixed the registration
  problems we were experiencing, but I can see where the search domain
  could also have impacts.

  Other use cases include externally managed automation, such as
  AWX/Ansible, which may rely on the FQDN being returned back by the
  instance in order to function correctly.

  Considering this is in the critical path for us to have functional, I
  believe that it merits discussion for change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2067183/+subscriptions