Bug 1316456 - Cluster REST api is inconsistend regarding scheduling policy
Cluster REST api is inconsistend regarding scheduling policy
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
Unspecified Unspecified
medium Severity medium (vote)
: ovirt-4.3.0
: ---
Assigned To: nobody nobody
Pavel Stehlik
: AutomationBlocker, Regression
Depends On:
  Show dependency treegraph
Reported: 2016-03-10 04:59 EST by Roman Mohr
Modified: 2017-09-28 04:32 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dfediuck: ovirt‑4.3?
rule-engine: blocker?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Roman Mohr 2016-03-10 04:59:27 EST
Description of problem:

The following scheduling policy description is embedded inside a cluster:
PUT /api/cluster/{cluster_id}
"id" : "{cluster_id}"
"scheduling_policy" : {
    "policy" : "evenly_distributed",
    "thresholds" : {
      "high" : "60",
      "duration" : "120"
    "properties" : {
      "property" : [ {
        "name" : "CpuOverCommitDurationMinutes",
        "value" : "2"
      }, {
        "name" : "HighUtilization",
        "value" : "60"
      } ]
    "name" : "evenly_distributed",
    "href" : "/ovirt-engine/api/schedulingpolicies/20d25257-b4bd-4589-92a6-c4c5c5d3fd1a",
    "id" : "20d25257-b4bd-4589-92a6-c4c5c5d3fd1a"
When you send the cluster with this embedded scheduling policy it will set the scheduling policy properties on the cluster.
When you follow the scheduling policy linkg

> "href" : "/ovirt-engine/api/schedulingpolicies/20d25257-b4bd-4589-92a6-c4c5c5d3fd1a"

and manipulate these properties there you are changing the scheduling policy itself on a system wide level and the cluster does not notice these changes.
That is inconsistent since from a user perspective always the object with the scheduling policy id

> 20d25257-b4bd-4589-92a6-c4c5c5d3fd1a

is manipulated.

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

How reproducible:

Steps to Reproduce:
1. Create a cluster and select a scheduling policy
2. Fetch the cluster through the REST API
3. Change a scheduling policy property and PUT the changed cluster
4. Visit the UI (you might have to refresh the page) and you will see the changed property on the cluster edit dialogue
5. Follow the cluster policy link and set the porperty there to a different value
6. The cluster still sees its property values

Actual results:
In one case you are manipulationg the cluster (although you are in the scheduling policy map with its own id) and when following the link you are manipulating the scheduling policy.

Expected results:

REST API confentions suggest that the scheduling policy object should be manipulated in both cases. However we need cluster specific properties. Either they should be moved out of the scope of the scheduling policy or we need cluster specific scheduling policis.

Additional info:
Comment 1 Roman Mohr 2016-03-10 05:02:03 EST
On 4.0 the embedded scheduling policy is now external which makes it currently impossible to set cluster scheduling properties through the REST API.
Comment 2 Sandro Bonazzola 2016-05-02 06:03:18 EDT
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Comment 3 Yaniv Lavi 2016-05-23 09:18:23 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 4 Yaniv Lavi 2016-05-23 09:22:27 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 5 Doron Fediuck 2016-06-30 08:52:36 EDT
Moving to 4.1, as this is the current implementation and not a regression.
Comment 6 Red Hat Bugzilla Rules Engine 2016-06-30 08:52:42 EDT
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.
Comment 7 Artyom 2016-06-30 09:03:38 EDT
I believe we need to up the severity, because it prevents from automation to check all built-in scheduling policies
Comment 8 Red Hat Bugzilla Rules Engine 2016-06-30 09:03:44 EDT
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Comment 9 Roman Mohr 2016-06-30 09:10:04 EDT
(In reply to Doron Fediuck from comment #5)
> Moving to 4.1, as this is the current implementation and not a regression.

It is a regression. It is one thing that the REST-API was always misleading. But in 4.0 it is now impossible to update the properties of a policy for a cluster. You always change the "template" policy which means that you set the property for all clusters which are using this policy. This was introduced by the REST-API refactoring for 4.0.

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