[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Metadata service caching old nameservers?

Hi Brian,

The lease does have the two Google nameservers in it, however a new VM 
is still somehow getting the old values as well. That is what is 
confusing me.  If it helps we are using Queens still currently.

Is there any database entry that I can change?

Many thanks for your help.


On 29/08/2019 20:32, Brian Haley wrote:
> On 8/29/19 6:26 AM, Grant Morley wrote:
>> Hi All,
>> We have a bit of a weird issue with resolv.conf for instances. We 
>> have changed our subnets in neutron to use googles nameservers which 
>> is fine. However it seems that when instances are launched they are 
>> still getting the old nameserver settings as well as the new ones. If 
>> I look at the metadata networking service it returns the old 
>> nameservers as well as the new ones below:
>> curl -i
>> HTTP/1.1 200 OK
>> Content-Type: text/plain; charset=UTF-8
>> Content-Length: 753
>> Date: Thu, 29 Aug 2019 09:40:03 GMT
>> {"services": [{"type": "dns", "address": ""}, {"type": 
>> "dns", "address": ""}, {"type": "dns", "address": 
>> ""}, {"type": "dns", "address": ""}]
>> In our neutron dhcp-agent.ini file we have the correct dnsmasq 
>> nameservers set:
>> dnsmasq_dns_servers =,
>> Are there any database tables I can change or clear up to ensure the 
>> old nameservers no longer get set? I can't seem to find any reference 
>> in our config any more of the old nameservers, so I assume one of the 
>> services is still setting them but I can't figure out what is.
> So does the DHCP response on lease renewal just have the two Google 
> nameservers in it?  If so, does a new VM booted on the subnet have the 
> correct metadata values reported?  Just trying to narrow-down if this 
> is in the neutron code or not.
> -Brian

Grant Morley
Cloud Lead, Civo Ltd
www.civo.com <https://www.civo.com/>| Signup for an account! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190830/3f3880e0/attachment-0001.html>