Hide Forgot
Description of problem: Though with UI an action of configuring weighted share to 105 (when the max default value is 100) is blocked as should be, with REST an action succeeds Steps to Reproduce: 1. Create network on DC/Cluster and attach it to host 2. Update weighted share to 105 (when the default on engine is 100 3. Actual results: An action succeeds Expected results: Actioin should fail Additional info: I did it with the python script that tests Polarion test case 6527 for Host QoS feature
Updating rate limit above 1024 succeeds as well when should fail (as on Engine 1024 is a default max value)
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Genadi, The scenario of (1) adding/updating host network qos is working for me. In case the value is not in the range I get the appropriate error. However, overriding the 'qos' via the (2) Add/UpdateNetworkAttachment or via (3) HostSetupNetworks actually doesn't present the error. In your bug, to what flow did you refer? If you referred to flow (1), please try to reproduce it again and update the bug with the result. Please also add an engine log.
I was talking about Network Attachment on the host
Martin, this bug is targeted 3.6.5 but referenced in 3.6.3 git log and on modified. can you please check?
Ok, now that the merged code has been reverted from 3.6.* branches, the bug can be quietly solved on the master branch.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Verified on - 4.0.0-0.0.master.20160423161403.gite38df80.el7.centos
oVirt 4.0.0 has been released, closing current release.