Bug 1176820 - Failed to set user defined scheduling policy via REST
Summary: Failed to set user defined scheduling policy via REST
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: x86_64
OS: Linux
Target Milestone: ovirt-3.6.1
: 3.6.1
Assignee: Roman Mohr
QA Contact: Artyom
Depends On:
TreeView+ depends on / blocked
Reported: 2014-12-23 11:45 UTC by Artyom
Modified: 2019-10-10 09:34 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Prior to Red Hat Enterprise Virtualization 3.5, the <policy>name</policy> tag was used to define the name of the scheduling policy to select. In 3.5, the <name>name</name> tag was introduced. By accident the policy tag was removed, which should be there for backward compatibility. As a result, user REST scripts for setting scheduling policies sometimes did not work. With this release, support for the <policy/> tag has been re-added. The <policy/> tag can now be used again, but <name/> is preferred if it is also present.
Clone Of:
Last Closed: 2016-03-09 20:53:39 UTC
oVirt Team: SLA
Target Upstream Version:
mgoldboi: Triaged+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 0 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 47917 0 master MERGED restapi: Document scheduling_policy.policy removal Never
oVirt gerrit 48083 0 ovirt-engine-3.6 MERGED restapi: Support policy tag in ClusterPolicy Never

Description Artyom 2014-12-23 11:45:03 UTC
Description of problem:
I created new scheduling policy and wanted to attach it to cluster via REST, but operation failed with next error:
<reason>Invalid value</reason>
cpu_filter is not a member of SchedulingPolicyType. Possible values for SchedulingPolicyType are: evenly_distributed, power_saving, none, vm_evenly_distributed

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create some custom scheduling policy
via REST looks like:
<scheduling_policy href= "/ovirt-engine/api/schedulingpolicies/18abab9b-a780-45c8-9727-3a925fda1703" id="18abab9b-a780-45c8-9727-3a925fda1703">
<link href= "/ovirt-engine/api/schedulingpolicies/18abab9b-a780-45c8-9727-3a925fda1703/filters" rel="filters"/>
<link href= "/ovirt-engine/api/schedulingpolicies/18abab9b-a780-45c8-9727-3a925fda1703/weights" rel="weights"/>
<link href= "/ovirt-engine/api/schedulingpolicies/18abab9b-a780-45c8-9727-3a925fda1703/balances" rel="balances"/>
<link href= "/ovirt-engine/api/schedulingpolicies/18abab9b-a780-45c8-9727-3a925fda1703/clusters" rel="clusters"/>
2. Try to attach scheduling to policy via REST:
PUT to specific cluster

Actual results:
<reason>Invalid value</reason>
cpu_filter is not a member of SchedulingPolicyType. Possible values for SchedulingPolicyType are: evenly_distributed, power_saving, none, vm_evenly_distributed

Expected results:
scheduling policy attached to cluster without any error messages

Additional info:
Via UI all works fine

Comment 1 Juan Hernández 2015-01-07 09:52:08 UTC
In the past scheduling policies used to be built-in entities, but recently they have been promoted to regular entities that the user can add/modify/delete. This means that the "policy" attribute can now be anything. But we didn't take this into account when we validate the value.

However, take into account that the recommended way to reference a scheduling policy is using the "id" or "name" attributes, so you could add the scheduling policy to the cluster with requests like this (using the id):

  PUT /clusters/{cluster:id}
    <scheduling_policy id="{schedulingpolicy:id}"/>

Or this (using the name):

  PUT /clusters/{cluster:id}

Using the "policy" attribute should work at least for the old built-in scheduling policies. It is good if it works for the new ones as well, but not a must in my opinion.

Anyhow, users (including the Python SDK) tend to update entities taking a complete entity and sending it again with all the attributes, not just the modified ones, so this problem will appear in many use cases.

I think that we should at least remove the validation of the policy type that we have in SchedulingPolicyValidator, and it would be good to also make sure that the "policy" attribute is accepted like "id" and "name" are.

Comment 2 Artyom 2015-01-08 16:23:19 UTC
Thanks to Juan

Comment 4 Roman Mohr 2015-10-21 12:42:20 UTC
Just checked the code and tried to reproduce the error. The property <policy/> does not exist anymore in 3.6. Only <name/> and <id/> can be used. 

The comment of Juan perfectly describes the situation in 3.5. <policy/> property can be used to add internal policies to the cluster, for custom policies <name/> or <id/> must be used.

Comment 6 Artyom 2015-11-29 09:36:13 UTC
Verified on rhevm-restapi-
Works fine.

Comment 9 errata-xmlrpc 2016-03-09 20:53:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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