get_default_dns_servers() is broken when use_rack_proxy = false
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Expired
|
Medium
|
Unassigned | ||
3.0 |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
So, we want to disable the use of the .maas-internal DNS domain, since we've found that sometimes it doesn't resolve for us when we're using an external proxy. I found that when the use_rack_proxy global setting is false, MAAS constructs phone-home URLs for cloud-init using IP addresses instead of using hostnames in the .maas-internal domain. But, started getting problems generating a new dhcpd.conf file after making this change, with this traceback:
2020-12-04 22:36:31 maasserver.
Traceback (most recent call last):
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
--- <exception caught here> ---
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
raise self.value.
File "/usr/lib/
result = result.
File "/usr/lib/
return g.throw(self.type, self.value, self.tb)
File "/usr/lib/
config = yield deferToDatabase
File "/usr/lib/
result = inContext.theWork()
File "/usr/lib/
File "/usr/lib/
return self.currentCon
File "/usr/lib/
return func(*args,**kw)
File "/usr/lib/
return func(*args, **kwargs)
File "/usr/lib/
result = func(*args, **kwargs)
File "/usr/lib/
return func_outside_
File "/usr/lib/
return func(*args, **kwargs)
File "/usr/lib/
return func(*args, **kwds)
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
elif default_region_ip in dns_servers:
Inspection of the code above shows a simple python type error which is easily corrected! The line in question is:
elif default_region_ip in dns_servers:
Earlier in this function, dns_servers is set to None if get_dns_
elif dns_servers and default_region_ip in dns_servers:
Changed in maas: | |
status: | New → Triaged |
importance: | Undecided → Medium |
milestone: | none → 3.0.1 |
Changed in maas: | |
milestone: | 3.0.1 → none |
Changed in maas: | |
status: | Incomplete → New |
status: | New → Incomplete |
We're running MAAS 2.8.2, btw. This bug doesn't appear to exist in 2.8.1, in quite the same way, as the function is implemented a bit differently.