Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1139590 - wrong nesting causing 'label name' and 'VmNetwork' change is not detected in canDoAction of UpdateNetworkCommand
Summary: wrong nesting causing 'label name' and 'VmNetwork' change is not detected in ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.5.0
Assignee: Martin Mucha
QA Contact: Meni Yakove
URL:
Whiteboard: network
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-09-09 09:38 UTC by Martin Mucha
Modified: 2016-02-10 19:47 UTC (History)
11 users (show)

Fixed In Version: vt3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 17:14:47 UTC
oVirt Team: Network
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 32658 master MERGED core: wrong nesting: not detecting label & VmNetwork changes Never
oVirt gerrit 32681 ovirt-engine-3.5 MERGED core: wrong nesting: not detecting label & VmNetwork changes Never

Description Martin Mucha 2014-09-09 09:38:10 UTC
last two lines is not properly nested, so changes to isVmNetwork and getLabel is not processed correctly.


return Objects.equals(oldNetwork.getName(), newNetwork.getName()) &&
                Objects.equals(oldNetwork.getDataCenterId(), newNetwork.getDataCenterId()) &&
                Objects.equals(oldNetwork.getId(), newNetwork.getId()) &&
                Objects.equals(oldNetwork.getMtu(), newNetwork.getMtu()) &&
                Objects.equals(oldNetwork.getName(), newNetwork.getName()) &&
                Objects.equals(oldNetwork.getProvidedBy(), newNetwork.getProvidedBy()) &&
                Objects.equals(oldNetwork.getStp(), newNetwork.getStp()) &&
                Objects.equals(oldNetwork.getVlanId(), newNetwork.getVlanId()) &&
                Objects.equals(oldNetwork.isVmNetwork(), newNetwork.isVmNetwork()) &&
                Objects.equals(oldNetwork.getLabel(), newNetwork.getLabel());

Comment 1 Lior Vernia 2014-09-16 11:30:29 UTC
Removing the CodeChange keyword; looking at the code, this should have caused a very specific bug that could have been found by end users.

If I'm not mistaken, prior to this change it would have been possible to update an existing network from non-VM to VM, if you also changed its label in the same operation. Then all validation would have been skipped, e.g. whether the network's name is already taken in the DC.

To conclude, scenario to test:
1. Set up a non-VM network.
2. Edit it; change it to VM network, and also change its label (it's okay if it didn't have a label before and you're adding a label). Also choose a name that should be taken by another network in the DC.
3. With this patch the operation should be blocked on the name being used; on an older deployment it should pass validation and perhaps even manage to change the network's name (or fail at a later point, e.g. throw a DB constraint violation exception in the engine log).

Comment 2 Michael Burman 2014-09-28 07:22:03 UTC
Verified on - 3.5.0-0.13.beta.el6ev

Comment 3 Eyal Edri 2015-02-17 17:14:47 UTC
rhev 3.5.0 was released. closing.


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