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'.

https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html

*** 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