Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

warning: in further convoluted text please discriminate between setupnetworks, which is vdsm command, and HostSetupNetworksCommand, which is bll command eventually calling former one.
---

I believe reason for this is, that DnsResolverConfiguration has enabled/disabled checkbox only in UI, but it's not propagated to bll. It's only there for validation purposes. Therefore we cannot discriminate between purposely empty dnsConfiguration (ie. remove nameservers from host) and unset dns configuration.

Currently it work like this. Mgmt from start (now) has default route role. Host probably does have some nameservers. If we'd consider empty dns configuration as meaningful, we'd erase dns configuration from host (or mark network out of sync, and erase configuration when syncing). So we instead did opposite: if dns configuration isn't present, it means 'do not change'.

You are correct! SetupNetworks is not issued, but that's implied(yet not nicely&directly), by things stated above. HostSetupNetworks will set nameservers using setupnetworks command only if they are defined on network or network attachment. Detection of out-of-sync must follow. What is not set by HostSetupNetworks must not be basis for network out of sync report. And here we're finally! coming to conclusion. During updating network, there's made check, whether the network is out-of-sync after update, and if it is, HostSetupNetworks will be executed. But if you delete dns configuration, it will be treated as no action, network will not be out of sync, and HostSetupNetworks won't be executed. And even if it would be invoked (which is not), it will not pass any dns change via setupnetworks command to vdsm. 

For engine, there is easy fix. Pass value of that enabled/disabled checkbox from UI (+similar fix for rest) as a flag 'I want to set this dns' to bll in parameters. All that mess above would clear up; if 'I want to set…' flag is set, and no DNS is provided it means, that we want to clear configuration.
 
However, same flag is missing on VDSM side, and even if we correctly pass empty list of nameservers to VDSM, it will be still evaluated as no-action, and old dns settings will be preserved.  Until vdsm part is fixed, fixing engine has only benefit of clearing up a little this unexpected behavior, but there will be no real fix.

---

Dan, please decide further steps. You think about CLOSE/WON'T-FIX, when we talk about it ...

At the moment, we do not allow removing of nameservers from hosts, only replacement of them. The main reason is so that we do not want to affect upgrading users, most of whom already have DNS defined outside oVirt (via DHCP or manually). Having no DNS defined in ovirt-engine means "don't change" rather than  "remove all".

As Mucha mentioned, a similar bug exists in ifcfg anyways; after defining DNS in ifcfg, it is added to resolv.conf. removing it from ifcfg would affect resolv.conf only after reboot.

We may readdress this issue in the future. Until then, users are advised to clean their resolv.conf out-of-band.

What about a scenario in which we have a DNS configured via the setup networks(override DNS) and we un checking the checkbox? 
The DNS configuration on the network should take place then. It's a real use case.

When host-level configuration is removed, Engine should apply the network-level configuration. If none of the two exist, it should keep the host configuration as it is.

[If Engine has no config (neither on network nor host) and the host itself reports one, Engine should keep considering the host as on-sync]

tested with fix for bug 1451261, and it works as expected, when maximum number of DNS address is passed in network/networkAttachment updates.

Scenario with lesser DNS addresses was not tested, because in that case vdsm error shows up. It does not override existing dns address, but adds new one.

To summarize comments 3# 4# and 5# - 

1) 'Networks' main tab scenario - Unchecking the 'DNS configuration' checkbox means - Having no DNS defined in ovirt-engine and it means "don't change".

- Note that at the moment, we do not allow removing of name servers from hosts, only replacement of them.


2) 'Override DNS' - Via the network attachment(setupNetworks) - Unchecking the 'DNS configuration checkbox means -  When host-level configuration is removed, engine should apply the network-level configuration. 
If none of the two exist, it should keep the host configuration as it is.

- Note that if Engine has no config (neither on network nor host) and the host itself reports one, engine should keep considering the host as synced.

(In reply to Martin Mucha from comment #6)
> tested with fix for bug 1451261, and it works as expected, when maximum
> number of DNS address is passed in network/networkAttachment updates.
> 
> Scenario with lesser DNS addresses was not tested, because in that case vdsm
> error shows up. It does not override existing dns address, but adds new one.

Hi

I can't understand this comment, not sure how it's related to the bug in the summary and the relevant scenario. 
Why this report related to BZ 1451261? and why it's on POST without any patches attached? does it deserves a fix of it's own or it's depends on the fix for BZ 1251261?

(In reply to Michael Burman from comment #8)
> (In reply to Martin Mucha from comment #6)
> > tested with fix for bug 1451261, and it works as expected, when maximum
> > number of DNS address is passed in network/networkAttachment updates.
> > 
> > Scenario with lesser DNS addresses was not tested, because in that case vdsm
> > error shows up. It does not override existing dns address, but adds new one.
> 
> Hi
> 
> I can't understand this comment, not sure how it's related to the bug in the
> summary and the relevant scenario. 
> Why this report related to BZ 1451261? and why it's on POST without any
> patches attached? does it deserves a fix of it's own or it's depends on the
> fix for BZ 1451261?

Michael, please retry with the currently merged patches.

Martin failed to verify one of your scenarios due to a Vdsm exception - I hope you would not bump into it yourself.

The only scenario which will be tested and verified here is - 
Removing host-level configuration(override DNS) should apply the network-level configuration.  

I have no idea what Martin is talking about. If he saw bug on vdsm side, please report one against vdsm. There is only one scenario here. 
What are those currently merged patches? where are they? i don't see any attached to this report.

I meant the https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:master+topic:defaultRoute-DNS patches which are available in current master.

(In reply to Dan Kenigsberg from comment #12)
> I meant the
> https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:
> master+topic:defaultRoute-DNS patches which are available in current master.

I still don't understand how those patches related to the report in the subject^.
I don't think they are. 
Note that those patches were applied for the default route bugs, and i just failed 3 of them. So don't sure what to say.
Any how i will test the relevant scenario for this spesific bug and we will see.

Have no idea how it worked as expected, but it worked.

Tested only the relevant scenario for this report - 

* TestA
1) 2 Hosts with 1 name server added to rhv
2) Edit and update ovirtmgmt with 2 new name servers: 8.8.8.8, 5.5.5.5
Changes applied successfully on the hosts.
3) Override 1 host with new DNS configuration(7.7.7.7) via setup networks > edit ovirtmgmt > DNS configuration>override
4) Override was applied successfully on the host1, but not on host2. 
5) Remove the override DNS configuration from the host 1 via the setup networks(uncheck the DNS configuration checkbox) - Expected result - 
name servers return to 8.8.8.8 and 5.5.5.5(the network-level applied) - PASS
6) Via networks tab ,edit ovirtmgmt and uncheck the DNS configuration checkbox, expected result - Nothing should be changed on the host, name servers should remain - 8.8.8.8 and 5.5.5.5 - PASS


* TestB 

1) 2 Hosts with 1 name server added to rhv
2) Override 1 host with 2 new DNS configurations(2.2.2.2 and 3.3.3.3) via setup networks
3) Override was applied successfully on the host1, but not on host2.
4) Remove the override DNS configuration from the host via the setup networks (uncheck the DNS configuration checkbox) - Expected result - Name servers should remain without change, as there is no network-level config to return to - PASS
name servers remain with 2.2.2.2 and 3.3.3.3.

As long as we have a network-level DNS config, we will return to it once host-level is removed.
If no network-level DNS exists, there should be no change when removing the host-level config. 

Verified on - ovirt-engine-4.2.0-0.0.master.20170721095131.git9f5e90c.el7.centos.noarch

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.