Description of problem: Memory overcommit should only accept allowed values- 100/150/200% in API, but instead it accepts all values this is a negative flow Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. create cluster 2. update memory overcommit to value != 100/150/200 Actual results: Update successfully to wrong value <memory_policy> <overcommit percent="76"/> </memory_policy> Expected results: should fail Additional info: This is true for all APIs - cli, java, python & rest Im putting this on medium because Im not sure what is the affect of having not allowed values set the failing test: https://rhev-jenkins.rhev-ci-vms.eng.rdu2.redhat.com:8443/view/3.6_Dev/job/3.6-GE-infra/174/testReport/rhevmtests.system.regression.component.test_clusters/007-TestCaseCluster_REST;test_update_cluster_memory_overcommit/TestCaseCluster_REST_test_update_cluster_memory_overcommit/
The API doesn't perform any validation on this value. If values other than 100/150/200 should be rejected then the backend should validate that and return the appropriate error message to the API.
This is the expected behavior and works by design. We allow other positive values using the REST API. If you can set a negative value, please reopen this BZ.
Reopened Indeed we are able to set positive values and in the UI the result is: Custom Overcommit Threshold - Set to 3% via API/CLI but when I set any negative value via the API it is set to 200%
(In reply to Nelly Credi from comment #3) > Reopened > > Indeed we are able to set positive values and in the UI the result is: > Custom Overcommit Threshold - Set to 3% via API/CLI > > but when I set any negative value via the API it is set to 200% Thanks. So this is mainly a harmless nit to ensure we either fail or set the default value (120%).
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
I just want to make sure you don't disable this feature: in fact we use this to allow for greater overcommits than 200% (which seems just a randomly chosen artificial limit anyway?) thanks Sven
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
(In reply to Sven Kieske from comment #6) > I just want to make sure you don't disable this feature: > > in fact we use this to allow for greater overcommits than 200% (which seems > just a randomly chosen artificial limit anyway?) > > thanks > > Sven Can someone maybe explain why this feature should be removed? Thanks Sven
oVirt 4.0 beta has been released, moving to RC milestone.
Since this is mostly harmless I'm closing for capacity reasons. If someone has a compelling reason to solve it, please reopen with the full explanation. Patches are always welcomed.
Reopening since there's a patch available. This will be handled for 4.1.
The suggested patch caused a regression. Closing this as we have more important issues to fix.