Bug 1489270
Summary: | Cloud-init fails to set dns_servers and dns_search on RHEL 7.4 VM | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Alex <alejandro.cortina2> | |
Component: | cloud-init | Assignee: | Ryan McCabe <rmccabe> | |
Status: | CLOSED ERRATA | QA Contact: | Vladimir <vshypygu> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 7.4 | CC: | aherr, alejandro.cortina2, cristi.falcas, dhill, fdelorey, fdinitto, jbadiapa, jgreguske, jherrman, lars, mavital, mmagr, mp19uy, mrunge, rmccabe, stirabos, vshypygu, xiachen | |
Target Milestone: | rc | Keywords: | Triaged, ZStream | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | cloud-init-0.7.9-22.el7 | Doc Type: | Bug Fix | |
Doc Text: |
Previously, the cloud-init service did not apply the DNS nameserver and DNS domain parameters if they were included in the network configuration for Red Hat Enterprise Linux 7 guest virtual machines. As a consequence, the guests were improperly configured. The nameserver and domain parameters are now applied correctly, and the applied network configuration works as expected.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1545525 (view as bug list) | Environment: | ||
Last Closed: | 2018-04-10 14:05:07 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 1473890 | |||
Bug Blocks: | 1545525 |
Description
Alex
2017-09-07 05:48:44 UTC
Since I cannot edit previous message: this happens on a new created vm and also on a template Could you please attach all your config files? Hi Ryan, although I am a rhce I am not an expert on this. Could you please tell me which config files should I attach? Cheers, Alex Hi, Any instance metadata, /etc/cloud/cloud.cfg, any network configuration file (network-config), if in use, and anything in /etc/cloud/cloud.cfg.d/, if anything exists there. Still waiting on upstream to take the fixes. The latest release (17.1) and the master branch are still broken. This also is happening in RHEL 7.3. In /var/log/cloud-init.log I see everything "normal": -------------------------------------------------------------------- ... 2017-10-10 15:43:25,930 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'subnets': [{'control': 'auto', 'dns_nameservers': ['8.8.8.8'], 'dns_search': ['my.dns.local.domain.com'], '_orig_eni_name': 'eth0', 'netmask': '255.255.255.0', 'address': '192.168.13.55', 'type': 'static', 'gateway': '192.168.13.1'}], 'type': 'physical', 'name': 'eth0'}]} 2017-10-10 15:43:25,930 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.rhel.Distro'> 2017-10-10 15:43:25,931 - __init__.py[DEBUG]: no interfaces to rename 2017-10-10 15:43:25,931 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 1, 'config': [{'subnets': [{'control': 'auto', 'dns_nameservers': ['8.8.8.8'], 'dns_search': ['my.dns.local.domain.com'], '_orig_eni_name': 'eth0', 'netmask': '255.255.255.0', 'address': '192.168.13.55', 'type': 'static', 'gateway': '192.168.13.1'}], 'type': 'physical', 'name': 'eth0'}]} 2017-10-10 15:43:25,936 - util.py[DEBUG]: Writing to /etc/sysconfig//network-scripts/ifcfg-eth0 - wb: [420] 179 bytes 2017-10-10 15:43:25,940 - util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-scripts/ifcfg-eth0 (recursive=False) 2017-10-10 15:43:25,941 - util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-scripts/ifcfg-eth0 (recursive=False) 2017-10-10 15:43:25,951 - util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False) 2017-10-10 15:43:25,952 - util.py[DEBUG]: Read 30 bytes from /etc/resolv.conf 2017-10-10 15:43:25,952 - util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [420] 101 bytes 2017-10-10 15:43:25,952 - util.py[DEBUG]: Restoring selinux mode for /etc/resolv.conf (recursive=False) 2017-10-10 15:43:25,953 - util.py[DEBUG]: Restoring selinux mode for /etc/resolv.conf (recursive=False) ... -------------------------------------------------------------------- But the content of /etc/resolv.conf is: -------------------------------------------------------------------- ; Created by cloud-init on instance boot automatically, do not edit. ; # Generated by NetworkManager -------------------------------------------------------------------- It fails to setup dns search parameter correctly As discussed via e-mail dns search parameter ends up in nameserver network_data: "availability_zone" : "nova", "hostname" : "dns", "launch_index" : "0", "meta" : { "role" : "server", "dsmode" : "local", "essential" : "false" }, "name" : "dns", "uuid" : "369dc0f8-c75d-48fc-9946-d16c3ab51f2c" "services" : [ { "address" : "8.8.8.8", "type" : "dns-nameserver" }, { "address" : "search.dns.test", "type" : "dns-search" } ] [root@dns ~]# cat /etc/resolv.conf ; Created by cloud-init on instance boot automatically, do not edit. ; # Generated by NetworkManager search scl.lab.tlv.redhat.com nameserver 8.8.8.8 nameserver search.dns.test P.S. I wasn't able to find anyone who can tell me how to setup dns search using openstack metadata protocol Where did you find the values "dns-nameserver" and "dns-search"? Cloud-init believes the only service that will ever show up is a nameserver, and treats every key there as a nameserver, regardless of the name. Has anybody reached out to somebody working on nova to figure out what the correct syntax is and whether it is possible to declare dns search in this manner? per https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py It looks like only nameservers are configurable via the services stanza using the 'dns' key. That is strange, because in the docs it has mentions of dns search, maybe not in that particular way but it sure has http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html Requirement itself comes from ovirt, and while I'm not quite sure if it's ever worked before, it surely must work. (In reply to Vladimir from comment #15) > That is strange, because in the docs it has mentions of dns search, maybe > not in that particular way but it sure has > http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1. > html > > Requirement itself comes from ovirt, and while I'm not quite sure if it's > ever worked before, it surely must work. That syntax is only valid for yaml config. The network_data.json is built to handle openstack's network_data.json, so there is not feature parity between the various ways to configure the networking. It looks like dns_nameservers and dns_search are valid keys under subnets for network_data.json, so you'd put them there instead of inside services. As far as I can tell, the only valid service type (read: key) for services is currently 'dns' and everything you put there is treated as if it is 'dns'. *** Bug 1534458 has been marked as a duplicate of this bug. *** So, it is not cloud-init problem, but how we pass config in RHEV-M, right? Could you paste what's being passed in, just to be completely sure? What you're passing in Comment 12 is not correct for what you want cloud-init to do. here is the network_data [root@virt-nested-vm07 payload]# cat /mnt/openstack/latest/network_data.json { "services" : [ { "address" : "1.2.3.4", "type" : "dns-nameserver" }, { "address" : "dns.search.test", "type" : "dns-search" } ] } and here is reolv.conf on the VM [root@dns_test ~]# cat /etc/resolv.conf ; Created by cloud-init on instance boot automatically, do not edit. ; # Generated by NetworkManager nameserver 1.2.3.4 nameserver dns.search.test Yeah, that won't work. The only key cloud-init expects inside services (and the only key nova ever puts there) is 'dns' (for nameservers) Can you please give me an example how to setup dns_search parameter in cloud-init? Here's an example adapted from the test config used in Bug 1519271 { "links" : [ { "name" : "eth1", "id" : "eth1", "type" : "vif" } ], "services" : [ { "address" : "search.foo.bar", "type" : "dns" } ], "networks" : [ { "netmask" : "255.255.255.0", "link" : "eth1", "id" : "eth1", "ip_address" : "10.0.0.1", "type" : "ipv4", "gateway" : "10.0.0.254", "dns_search": "search.example.com" }, { "link" : "eth1", "id" : "eth1", "type" : "ipv6_dhcp" } ] } The only real change is the "dns_search": "search.example.com" under networks Verified manually using Openstack metadata format using cloud-init-0.7.9-22.el7.x86_64 Checked following scenarios: 1. Set DNS server 2. Set DNS search 3. Set both DNS server and DNS search Example format { "links" : [ { "name" : "eth1", "id" : "eth1", "type" : "vif" } ], "services" : [ { "address" : "1.2.3.4", "type" : "dns-nameserver" }], "networks" : [ { "netmask" : "255.255.255.0", "link" : "eth1", "id" : "eth1", "ip_address" : "10.0.0.1", "type" : "ipv4", "gateway" : "10.0.0.254", "dns_search": "search.example.test" }, { "link" : "eth1", "id" : "eth1", "type" : "ipv6_dhcp" } ] moving to verified according to comment 27 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-2018:0806 |