The following nmstate configuration does not apply even though it's expected it should ``` desiredState: dns-resolver: config: search: - test.com server: - fd2e:6f44:5dd8:c956::1 - 2099::9999 interfaces: - name: enp1s0 type: ethernet state: up ipv4: auto-dns: false dhcp: false enabled: false ipv6: auto-dns: false dhcp: false enabled: false ``` After removing the `dns-resolver` section we get a config that applies correctly, i.e. ``` desiredState: interfaces: - name: enp1s0 type: ethernet state: up ipv4: auto-dns: false dhcp: false enabled: false ipv6: auto-dns: false dhcp: false enabled: false ``` The config with only dns-resolver also does not apply ``` desiredState: dns-resolver: config: search: - test.com server: - fd2e:6f44:5dd8:c956::1 - 2099::9999 ``` All this definitely points towards dns-resolver section as the one at fault. In all the scenarios when we fail, the error returned is ``` nmstate::nm::query_apply::profile] Got activation failure Bug: Manager(UnknownDevice): No suitable device found for this connection (device [...] not available because profile is not compatible with device (mismatching interface name)). ``` with interface name in the error message being not necessarily the one that we configure (because with only dns-resolver section we don't configure any interface explicitly). This is a regression because in the current form we have no way of using nmstate to configure DNS. Because of this, we do need a backport to RHEL 9.2 z-stream
To reproduce this problem, you need system with IP disabled on all interfaces. Create a OVS bridge with geneve interface type with command: sudo ovs-vsctl add-port br0 gen0 -- set interface gen0 type=geneve options:remote_ip=192.168.56.12 options:key=123 Afterwards, assign IPv6 address to interface `genev_sys_6081` using `ip` command. Finally, try to change DNS with IPv6 nameserver. Expected behavior should be: * The `genev_sys_6081` should be marked as `state: ignore`. * The DNS is stored as global DNS. Patch posted to upstream: https://github.com/nmstate/nmstate/pull/2398
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.