Bug 1271220

Summary:	[REST] [Host network QoS] It's possible to configure weighted share and rate limit on the network to be bigger than the max value configured on engine
Product:	[oVirt] ovirt-engine	Reporter:	GenadiC <gcheresh>
Component:	BLL.Network	Assignee:	Martin Mucha <mmucha>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Meni Yakove <myakove>
Severity:	medium	Docs Contact:
Priority:	low
Version:	3.6.0	CC:	alkaplan, bugs, danken, dfediuck, gcheresh, mburman, mmucha, ncredi, sbonazzo, ylavi
Target Milestone:	ovirt-4.0.0-alpha	Keywords:	Automation
Target Release:	4.0.0	Flags:	rule-engine: ovirt-4.0.0+ rule-engine: blocker+ ylavi: planning_ack+ rule-engine: devel_ack+ myakove: testing_ack+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-05 07:42:02 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 GenadiC 2015-10-13 12:07:02 UTC

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

Comment 1 GenadiC 2015-10-19 10:44:55 UTC

Updating rate limit above 1024 succeeds as well when should fail (as on Engine 1024 is a default max value)

Comment 2 Yaniv Lavi 2015-10-29 12:42:06 UTC

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.

Comment 3 Alona Kaplan 2015-11-19 17:05:57 UTC

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.

Comment 4 GenadiC 2015-11-25 10:29:27 UTC

I was talking about Network Attachment on the host

Comment 5 Sandro Bonazzola 2016-01-27 13:48:50 UTC

Martin, this bug is targeted 3.6.5 but referenced in 3.6.3 git log and on modified. can you please check?

Comment 6 Dan Kenigsberg 2016-02-01 11:36:46 UTC

Ok, now that the merged code has been reverted from 3.6.* branches, the bug can be quietly solved on the master branch.

Comment 7 Mike McCune 2016-03-28 23:09:17 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 8 Michael Burman 2016-04-25 08:51:43 UTC

Verified on - 4.0.0-0.0.master.20160423161403.gite38df80.el7.centos

Comment 9 Sandro Bonazzola 2016-07-05 07:42:02 UTC

oVirt 4.0.0 has been released, closing current release.