Created attachment 1273883 [details] Logs Description of problem: Engine not sending defaultRoute property on setup networks command. Looks like engine is not sending 'defaultRoute': on setup networks call - MainProcess|jsonrpc/6::DEBUG::2017-04-25 14:41:55,230::supervdsm_server::92::SuperVdsm.ServerCallback::(wrapper) call setupNetworks with ({}, {u'connectivityCheck': u'true', u'connectivityTimeout': 120}) {} MainProcess|jsonrpc/6::DEBUG::2017-04-25 14:41:55,230::api::209::root::(setupNetworks) Setting up network according to configuration: networks:{u'default_route_n': {u'ipv6autoconf': False, u'nic': u'ens1f1', u'mtu ': 1500, u'switch': u'legacy', u'dhcpv6': False, u'STP': u'no', u'bridged': u'true'}}, bondings:{}, options:{u'connectivityCheck': u'true', u'connectivityTimeout': 120} { "ipv6autoconf": false, "nameservers": [], "nic": "ens1f1", "mtu": 1500, "switch": "legacy", "dhcpv6": false, "stp": false, "bridged": true, "defaultRoute": false, "bootproto": "none" } /var/lib/vdsm/persistence/netconf/nets/default_route_n Version-Release number of selected component (if applicable): 4.2.0-0.0.master.20170424080141.git6c29d86.el7.centos Steps to Reproduce: 1. Create new network and set it with Default Route property via 'Networks>'Clusters'>manage networks 2. Attach this network to the host Actual results: engine not sending 'defaultRoute' on a setup networks call Expected results: Should work
current code expects from default route to have dhcp boot proto, or static boot proto with ip. Otherwise it's ignored, also with dns configuration. If you set attachment to have dhcp boot proto, it will probably work for you. if this is not correct, please let me know, what is expected behavior.
(In reply to Martin Mucha from comment #1) > current code expects from default route to have dhcp boot proto, or static > boot proto with ip. Otherwise it's ignored, also with dns configuration. If > you set attachment to have dhcp boot proto, it will probably work for you. > > if this is not correct, please let me know, what is expected behavior. Correct. Please see BZ 1438445, as we must require a bootproto for the default route network. The expected behaviour is to require bootproto for default route network.
(In reply to Michael Burman from comment #2) > (In reply to Martin Mucha from comment #1) > > current code expects from default route to have dhcp boot proto, or static > > boot proto with ip. Otherwise it's ignored, also with dns configuration. If > > you set attachment to have dhcp boot proto, it will probably work for you. > > > > if this is not correct, please let me know, what is expected behavior. > > Correct. Please see BZ 1438445, as we must require a bootproto for the > default route network. > The expected behaviour is to require bootproto for default route network. I believe BZ 1438445 is irrelevant. This bug just solves, that when giving network default route role, all it's current attachments must have static or dhcp boot proto. It says nothing about not yet existing attachments. Code here, is different dialog, in which, when network with default route role is being attached, dns configuration data will be silently ignored, when such network does not have static ip (and then also ipv4 or ipv6 address) or dhcp bootproto. So expected action is what? a) silent ignoration is OK! b) validation error on UI side c) warning, but proceeding d) ...?
(this is usecase I tried to describe to you in mail. There should be reference to this bug as well). Please advise, what is expected action of engine.
(In reply to Martin Mucha from comment #3) > I believe BZ 1438445 is irrelevant. This bug just solves, that when giving > network default route role, all it's current attachments must have static or > dhcp boot proto. It says nothing about not yet existing attachments. What happens when a user attempts to attach a role network but does not supply its ip/dhcp? I believe that the setupNetwork command should fail with an error.
(In reply to Dan Kenigsberg from comment #5) > (In reply to Martin Mucha from comment #3) > > I believe BZ 1438445 is irrelevant. This bug just solves, that when giving > > network default route role, all it's current attachments must have static or > > dhcp boot proto. It says nothing about not yet existing attachments. > > What happens when a user attempts to attach a role network but does not > supply its ip/dhcp? I believe that the setupNetwork command should fail with > an error. Indeed. From both sides, if user trying to attach role network without bootproto we fail with: 'Cannot setup Networks. Role (migration/display/gluster) network 'e' hasn't boot protocol assigned.' If user trying to assign network that is already attached to host with role(via manage clusters) we fail with: 'Error while executing action: Cannot edit Network. IP address has to be set for the NIC that bears a role network. Network: e, Nic: bond0 on host orchid-vds1.qa.lab.tlv.redhat.com violates that rule.' Same behaviour should be for default route role network, as requested in BZ 1438445
good, now I understand that better. verifying this scenario, I found duplicate code, which was overlooked when working on BZ 1438445. Both locations has to be fixed there (and now they are), and this also 'fixes' this bug. Now there is in place validation for attached default route network, which guarantees that no attached default route network will have NONE boot proto and that static bootproto will miss ip. That kinda nullifies reason for having org.ovirt.engine.core.bll.network.host.ShouldSetDefaultRouteFlagAndDnsData#test, and kind code reviewer can advice if it could be removed.
FailedQA. Tested on 4.2.0-0.0.master.20170721095131.git9f5e90c.el7.centos and vdsm-4.20.1-218.git1b7671f.el7.centos.x86_64 Can't attach non-mgmt network to host with default route role. This bug depends on BZ 1443292, with out it this can't be tested at all.
Verified on - 4.2.0-0.0.master.20170917124606.gita804ef7.el7.centos
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.