Bug 1536397

Summary: CloudInit: DNS search parameter is passed incorrectly
Product: Red Hat Enterprise Virtualization Manager Reporter: Vladimir <vshypygu>
Component: ovirt-engineAssignee: eraviv
Status: CLOSED ERRATA QA Contact: meital avital <mavital>
Severity: medium Docs Contact:
Priority: low    
Version: 4.2.0CC: danken, lsurette, mavital, mtessun, rdlugyhe, Rhev-m-bugs, rmccabe, srevivo
Target Milestone: ovirt-4.3.0   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.3.0_alpha Doc Type: Bug Fix
Doc Text:
Previously, CloudInit passed the dns_search value incorrectly as the dns_namesever value. For example, after configuring a the Networks settings of a virtual machine and runinng it, the dns_search value showed up in the resolv.conf file as the dns_namesever value. The current release fixes this issue.
Story Points: ---
Clone Of:
: 1566341 (view as bug list) Environment:
Last Closed: 2019-05-08 12:36:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1566341    
Attachments:
Description Flags
cloud-init.log , engine.log, network_data.json none

Description Vladimir 2018-01-19 10:54:31 UTC
Description of problem:
dns search parameter doesn't work know, everything that is passed as dn_search ends up being dns_namesever

Version-Release number of selected component (if applicable):
4.2.1.1-0.1.el7

How reproducible:
100%

Steps to Reproduce:
1. Create VM with initial run enabled
2. Configure 4.2.1.1-0.1.el7 under Networks
3. Run VM

Actual results:
dns search is configured as nameserver in the resolv.conf

Expected results:

dns search is configured correctly in the resolv.conf

Additional info:

It seems that the problem lies in the incorrect network_data.json, check discussion with Ryan here https://bugzilla.redhat.com/show_bug.cgi?id=1489270

Comment 1 Dan Kenigsberg 2018-01-21 11:00:13 UTC
Vladimir, please provide Engine log, cloud init logs (and cloudinit version!). In particular, if you think the problem is a bad network_data.json, please attach it here.

Comment 3 Vladimir 2018-01-22 13:59:28 UTC
Created attachment 1384447 [details]
cloud-init.log , engine.log, network_data.json

Comment 5 eraviv 2018-03-04 08:16:56 UTC
Hi Ryan,
I am trying to fix the dns nameserver issue in our network_data.json (key should be 'dns' - according to what Vladimir mentions in the first comment):

When I apply both a network configuration and a dns nameserver configuration:

{
  "links" : [ {
    "name" : "eth0",
    "id" : "eth0",
    "type" : "vif"
  } ],
  "services" : [ {
    "address" : "8.8.8.8",
    "type" : "dns"
  }, {
    "address" : "111.111.111.101",
    "type" : "dns"
  } ],
  "networks" : [ {
    "netmask" : "255.255.255.0",
    "link" : "eth0",
    "id" : "eth0",
    "ip_address" : "192.168.122.111",
    "type" : "ipv4",
    "gateway" : "192.168.122.1"
  } ]
}

I get the expected result in /etc/resolv.conf:

# cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
; generated by /usr/sbin/dhclient-script
nameserver 192.168.122.1
nameserver 8.8.8.8
nameserver 111.111.111.101

------------------------------------------------

But when i specify only the nameservers in my configuration:

{
  "services" : [ {
    "address" : "8.8.8.8",
    "type" : "dns"
  }, {
    "address" : "111.111.111.101",
    "type" : "dns"
  } ]
}

they do not get written to /etc/resolv.conf:

; generated by /usr/sbin/dhclient-script
nameserver 192.168.122.1

----------------------------------------------------
i am using the latest rpm you gave me:

# rpm -q cloud-init
cloud-init-0.7.9-20test1.el7.x86_6

Any idea?
Thanks

Comment 6 eraviv 2018-03-04 12:10:45 UTC
update for above:

I ran some more tests and found that for network_data.json:

{
  "services" : [ {
    "address" : "8.8.8.8",
    "type" : "dns"
  }, {
    "address" : "111.111.111.101",
    "type" : "dns"
  } ]
}

- if there is any content in /etc/resolv.conf - the nameservers from the network_data.json of the latest run are NOT added to /etc/resolv.conf.
- if /etc/resolv.conf is completely erased, the nameservers from the network_data.json of the latest run are added to it. 
- so my previous suspicion that networks need to be present in network_data.json is not true - the problem is that there was content in /etc/resolv.conf

---------------------------------------------------------------
here is /etc/resolv.conf for the above json:

# cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
nameserver 8.8.8.8
nameserver 111.111.111.101

And after several consequetive runs without erasing:

; Created by cloud-init on instance boot automatically, do not edit.
;
; Created by cloud-init on instance boot automatically, do not edit.
;
; Created by cloud-init on instance boot automatically, do not edit.
;
nameserver 8.8.8.8
nameserver 111.111.111.101


---------------------------------------------------------
BTW, AFAIU the initial content generated by the dhclient script is because the initial centos image i downloaded had cloud-init-0.7.9.9 on it, and i had to start the vm without any network configuration in order to install cloud-init-0.7.9-20test1.el7.x86_6.

Comment 7 eraviv 2018-03-04 12:28:46 UTC
After some more tests, I think I can narrow down the problem:

If the current network_data.json contains a static ip network, or if there already is an ifcfg with a static ip configuration - then the dhclient is not invoked and the dns's from the services clause are applied by cloud-init to /etc/resolv.conf
Otherwise, dhclient is called and over-writes the content in /etc/resolv.conf resulting in no dns's from the network_data.json there.

Comment 8 eraviv 2018-03-04 21:22:51 UTC
looking at cloud-init code at sysconfig.py i see that indeed dns's specified for an interface is only written if the configuration of the interface is static. is this also true for the dns's specified under the services clause?

Comment 9 Ryan McCabe 2018-03-05 01:35:03 UTC
(In reply to eraviv from comment #8)
> looking at cloud-init code at sysconfig.py i see that indeed dns's specified
> for an interface is only written if the configuration of the interface is
> static. is this also true for the dns's specified under the services clause?

If you specify nameservers in the services stanza, cloud-init will drop a file in /etc/NetworkManager/conf.d telling it to not manage dns so that nameserver configuration from dhcp won't clobber what's been written to /etc/resolv.conf by cloud-init. The entries you provided should be there.

If there have been previous runs, cloud-init will load all the nameservers that exist in /etc/resolv.conf and write them back out, but it enforces a 3 nameserver limit per resolv.conf(5), so that may potentially cause problems, causing output to be truncated. Output loaded from resolv.conf will be written before new configuration.

Comment 10 eraviv 2018-03-05 04:55:46 UTC
so what is the correct method of passing nameservers to cloud-init?

- only on subnets if subnets are configured
- only on the services stanza
- on both
- on subnets if they are static and on services stanza if they are dhcp
- other?

is this documented anywhere?

thanks

Comment 13 RHV bug bot 2018-12-10 15:13:20 UTC
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 14 Pedut 2018-12-13 13:11:03 UTC
Verified on 4.3.0-0.4.master.20181207184726.git7928cae.el7.
The following test scenarios were tested:
1. no networks, only dns nameservers
> The dns nameservers were written to /etc/resolv.conf and to network_data.json as it should.
2. no networks, only search domains
> Nothing was written to /etc/resolv.conf and and the file network_data.json wasn't created as it should.
3. no networks, dns nameservers + search domains.
> The dns nameservers were written to /etc/resolv.conf and to network_data.json as it should.
4. network with static\dhcp ipv4, dns nameservers + search domains
> The dns nameservers were written to /etc/resolv.conf and all the configurations were written to network_data.json as it should.
5. network with static\dhcp ipv6, dns nameservers + search domains
> The dns nameservers were written to /etc/resolv.conf and all the configurations were written to network_data.json as it should.
6. network with static\dhcp ipv4 + static\dhcp ivp6, dns nameservers + search domains
> The dns nameservers were written to /etc/resolv.conf and all the configurations were written to network_data.json as it should.

Comment 15 RHV bug bot 2019-01-15 23:35:47 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 18 errata-xmlrpc 2019-05-08 12:36:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085