-
Bug
-
Resolution: Done
-
Normal
-
None
-
rhos-18.0.z
-
None
-
False
-
-
False
-
?
-
rhos-connectivity-nfv
-
None
-
-
-
-
Critical
To Reproduce Steps to reproduce the behavior:
When RHOSO EDPM nodes are deployed with "edpm_network_config_nmstate: true" (as current version of document recommends), users end up with irrelevant /etc/resolv.conf that doesn't match original os-net-config configuration.
The problem is that despite the fact that DNS server is translated properly from os-net-config to NetworkManager's config (
[.intern.global-dns-domain-*]
section specifically), NetworkManager doesn't translate it to /etc/resolv.conf.
Senior peer from networking support group pointed out that the reason is "dns=none" definition in /etc/NetworkManager/NetworkManger.conf, which is also provision by EDPM Ansible playbooks.
AFAIR, "dns=none" definition was set at some point to overcome cloud-init problem. Not sure how relevant it is now, but in any case some solution is needed.
Expected behavior
nmstate provider provisions network configuration consistently
Bug impact
All customers following current version of document will end up having unreliable /etc/resolv.conf contents: in some cases they will be good, in some – they wont.
Known workaround
To manually change /etc/resolv.conf contents, or to use different os-net-config provider
Additional context
Sosreport from EDPM node and must-gather attached to case