Bug 1566341 - [downstream clone 4.2.4] CloudInit: DNS search parameter is passed incorrectly
Summary: [downstream clone 4.2.4] CloudInit: DNS search parameter is passed incorrectly
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.2.2
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ovirt-4.2.3
: ---
Assignee: eraviv
QA Contact: Vladimir
URL:
Whiteboard:
Depends On: 1536397
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-12 06:24 UTC by eraviv
Modified: 2019-04-24 20:57 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1536397
Environment:
Last Closed: 2018-05-14 15:11:59 UTC
oVirt Team: Network
mavital: needinfo+
rule-engine: ovirt-4.2+
ylavi: exception+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 88450 0 None None None 2018-04-12 06:24:03 UTC
oVirt gerrit 90203 0 ovirt-engine-4.2 MERGED core: cloud-init DNS nameserver and search parameters 2018-04-25 08:12:01 UTC

Comment 1 Michael Burman 2018-04-29 05:18:02 UTC
Hi Mietal, can you please take this one on you? the original report was done by Vladimir in BZ 1536397

Comment 3 eraviv 2018-05-08 09:08:56 UTC
Hi Vladimir,

Please note the following points:

1. the guest os must contain an updated version of cloud-init. I would say at least 0.7.9-21, in order for cloud-init to process the dns configuration according to the openstack recommendations which is what RHEV is also bound to. So run the vm without dns config, yum update cloud-init, and then test.

2. according to what i was able to find in cloud-init docs + source code and according to my own tests:

a. DNS nameservers (up to three are supported by cloud-init) and search domains (up to 6) will be added to the ifcfg file of the network and /etc/resolv.conf if the network is static (i.e. is configured with static IP).

b.DNS nameservers (up to 3 supported by cloud-init) will be applied directly to /etc/resolv.conf, in case no networks are specified or all networks are configured with dhcp. 

If the vm is restarted, existing entries in /etc/resolv.conf are reapplied first, and newer ones are appended only if there are less than 3.

If nameservers are specified, 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 overwrite what's been written to /etc/resolv.conf by cloud-init.

3. Cloud-init writes the search domain key and value to ifcfg, so the key name is not a RHEV decision. AFAIK, DOMAIN is the correct key for a search domain in ifcfg.

Comment 4 Vladimir 2018-05-08 12:03:29 UTC
And what if I specify dns search domain without interface configuration? Right now it doesn't get anywhere, if I'm correct

Comment 5 eraviv 2018-05-09 07:43:26 UTC
According to Ryan's explanation in https://bugzilla.redhat.com/show_bug.cgi?id=1489270#c17 this looks like a valid outcome because he says cloud-init treats all non-interface-specific entries as nameserver entries.

Comment 6 Vladimir 2018-05-10 10:51:36 UTC
This is misleading for users then, since you can specify dns search in the initial run -> dns section, but it won't get anywhere if you don't have iface configured. Can we move it to the iface section and document it then?

Comment 8 Vladimir 2018-05-14 11:28:49 UTC
Verified on 4.2.3.5-0.1.el7

Dns search parameter is passed correctly now. 

Tested following configurations:

IPv4 static
IPv6 static
IPv4 static + IPv6 static
IPv4 dhcp + IPv6 dhcp
IPv4 static + IPv6 dhcp
IPv4 dhcp + IPv6 static

In all configurations dns search parameter is passed to the cloud-init correctly

Comment 9 Sandro Bonazzola 2018-05-14 15:11:59 UTC
This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.3 release, it has been closed with a resolution of CURRENT RELEASE.

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


Note You need to log in before you can comment on or make changes to this bug.