Bug 1269167
Summary: | Setup Network operations will fail if one of the networks has been changed(vlan for example) and can't be synced back to host | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Michael Burman <mburman> |
Component: | BLL.Network | Assignee: | Nobody <nobody> |
Status: | CLOSED NOTABUG | QA Contact: | Michael Burman <mburman> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.6.0 | CC: | bazulay, bugs, danken, ecohen, gklein, lsurette, mburman, rbalakri, Rhev-m-bugs, yeylon, ylavi |
Target Milestone: | ovirt-4.0.0-alpha | Flags: | ylavi:
ovirt-4.0.0?
rule-engine: planning_ack? mburman: devel_ack? rule-engine: testing_ack? |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | network | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-10 12:02:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michael Burman
2015-10-06 13:43:39 UTC
Sorry this bug is entirely unclear. Please use the axact dialogs you used specify exactly what butten pressed. And what exactly failed (and at what point of time) Hi Barak, Ok, i will try to make it clearer : 1) Create 1 VM network 'net-1' via Networks tab (press 'ok' to approve operation) 2) Create 1 VM vlan 'net-2' tagged network via Networks tab(press 'ok' to approve operation) 3) Attach both networks to 1 NIC on host via the Setup Networks dialog and approve operation 4) Via the Networks tab, edit 'net-2' (the vlan network) to be non-vlan network and press 'ok' to approve operation. Results --> - Setup networks command is sent to host, but failed, because 2 non-vlan networks can't live together. - 'net-2' network now considered as unsynced network and reported as 'out-of-sync' in the 'out-of-sync' column and in the setup networks dialog. There is now a difference on the vlan property for 'net-2' network between DC and HOST. * So the problem is that step 4 wasn't blocked by engine like we would like it to behave. Engine should recognize that performing action like on step 4 should be blocked, because 2 non-vlan networks can't live together on 1 NIC. And because step 4 wasn't blocked by engine, we have now situation on which 'net-2' is unsynced and we can't perform any other setup network operation on the host and we can't sync both networks. All we can do is detach 'net-2 from host or to edit it back to vlan network. Hope this was much clearer, Thanks Hi Michael, I don't understand why do you think step 4 should be blocked. What if the network is used by multiple hosts, do you think that if the 'setupNetworks' operation may fall on one of the host the vlan change of the network should be blocked? When changing a property like 'vlanId' on the network two actions are performed- 1. Changing the vlan of the network. 2. Updating all the hosts that are using the network. Step 2 can fail on a specific host for multiple reasons- can do action failure, host that is down or any other reason. That doesn't mean that step 1 and step 2 for all the other hosts should be blocked. And also, the setup networks of the host with the unsync network is not blocked. Only updates on the nic that contains the problematic network are block. You can do changes on the other nics. Hi Alona, As agreed, we need to discuss this with Meni and Danken . As far as I understand, multi-host networking action behaves as planned. We should not fail the action on the whole DC just because one of the hosts has a conflicting local configuration. such host ends up with a network in an out-of-sync state, to be solved manually by the user (by forcing Sync or removing an offending config). I would not like to add another validation, unless many customers complain, as we are commonly asked "not to nanny the user". |