Bug 2123478 - dns-nameservers settings appears to be broken in train 16.2.3
Summary: dns-nameservers settings appears to be broken in train 16.2.3
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 16.2 (Train)
Hardware: All
OS: All
high
medium
Target Milestone: ---
: ---
Assignee: Elvira
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-01 18:45 UTC by David Hill
Modified: 2023-07-28 16:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-28 16:14:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-18518 0 None None None 2022-09-01 18:57:44 UTC

Description David Hill 2022-09-01 18:45:09 UTC
Problems :
             1/ When a VM is created in a subnet with a default DNS value defined as 0.0.0.0
                  -> The VM file /etc/resolv.conf is not empty (as expected) but have the value 0.0.0.0
             2/ When a VM is created in a subnet where the option --dns-nameserver is used to have no DNS defined at the subnet level
                  -> The VM file /etc/resolv.conf is not empty (as expected) and will have the value of the default DNS of the UnderCloud
                  -> More over : if a default value should has been taken it should be value of :
                                  - dns_nameservers pram in the  ~/undercloud.conf file   OR
                                  - DnsServers param in the ~/templates/environments/network-environment-overrides.yaml


### After the UpGrade from 16.2.1 to 16.2.3 we have done the following tests :
Intro :
            We have used two diffèrent images to to create the tests VM :
                  -> VM with CIRROS Image
                  ->  VM with Almalinux image
Spoil :
            The tests show that :
                  -> The result can depend on the VM image
                  -> The behaviour of the VMs can be very complecated depending on the test scenario
Tests détails :
            1a/ Create the VM in a subnet with no DNS using the --no-dns-nameservers option
                  -> VM Cirros : /etc/resolv.conf value at 10.10.10.10 (undercloud default DNS)
                  -> VM Almalinux : /etc/resolv.conf value at 10.10.10.10 (undercloud default DNS)
            1b/ Define the DNS subnet value as 0.0.0.0 AND then reboot the VM in the subnet with the DNS value at 0.0.0.0
                  -> VM Cirros : /etc/resolv.conf value at 0.0.0.0
                  -> VM Almalinux : /etc/resolv.conf value at empty !!!
            1c/ Destroy the VM AND then deploy it again in the subnet with DNS value at 0.0.0.0
                  -> VM Cirros : /etc/resolv.conf value at 0.0.0.0
                  -> VM Almalinux : /etc/resolv.conf value at 0.0.0.0
            1d/ Reboot the VM in the subnet with DNS value at 0.0.0.0
                  -> VM Cirros : /etc/resolv.conf value at 0.0.0.0
                  -> VM Almalinux : /etc/resolv.conf value at 0.0.0.0
            1e/ Define the DNS subnet value as empty with the --no-dns-nameservers  option AND then reboot the VM
                  -> VM Cirros : /etc/resolv.conf value at 10.10.10.10
                  -> VM Almalinux : /etc/resolv.conf value at 0.0.0.0 
            1f/ Define the DNS subnet value at 0.0.0.0 AND then reboot the VM
                  -> VM Cirros : /etc/resolv.conf  value at 0.0.0.0
                  -> VM Almalinux : /etc/resolv.conf value at 0.0.0.0

Comment 1 David Hill 2022-09-01 19:26:16 UTC
I just reproduced this with a RHEL 8.4 :

[cloud-user@test-dave ~]$ cat /etc/resolv.conf 
; Created by cloud-init on instance boot automatically, do not edit.
;
nameserver 0.0.0.0

Comment 2 David Hill 2022-09-01 19:51:17 UTC
[root@overcloud-vcontroller-0 ~]# podman exec -i ovn-dbs-bundle-podman-0 ovn-nbctl list DHCP
_uuid               : b172bfaa-8683-4192-b5ff-68460bb2121c
cidr                : "10.0.0.0/24"
external_ids        : {"neutron:revision_number"="1", subnet_id="197b33d2-53cf-41df-b8f2-11535e08cdc4"}
options             : {classless_static_route="{169.254.169.254/32,10.0.0.100, 0.0.0.0/0,10.0.0.1}", dns_server="{0.0.0.0}", lease_time="43200", mtu="1500", router="10.0.0.1", server_id="10.0.0.1", server_mac="fa:16:3e:01:35:0d"}


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