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());
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).
Verified on - 3.5.0-0.13.beta.el6ev
rhev 3.5.0 was released. closing.