Bug 1334098 - Scheduling policy doesnt get updated in REST (v3)
Summary: Scheduling policy doesnt get updated in REST (v3)
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.0.0-rc2
: ---
Assignee: Juan Hernández
QA Contact: Artyom
Depends On:
TreeView+ depends on / blocked
Reported: 2016-05-08 11:34 UTC by Nelly Credi
Modified: 2016-07-05 07:58 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-07-05 07:58:30 UTC
oVirt Team: Infra
rule-engine: ovirt-4.0.0+
rule-engine: blocker+
rule-engine: planning_ack+
oourfali: devel_ack+
pstehlik: testing_ack+

Attachments (Terms of Use)
engine logs (516.10 KB, application/x-bzip)
2016-05-08 11:34 UTC, Nelly Credi
no flags Details

System ID Private Priority Status Summary Last Updated
oVirt gerrit 57248 0 master MERGED restapi: Fix cluster scheduling policy update 2016-05-13 15:43:57 UTC

Description Nelly Credi 2016-05-08 11:34:06 UTC
Created attachment 1155038 [details]
engine logs

Description of problem:
in v3
scheduling policy doesnt get updated in REST

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

How reproducible:

Steps to Reproduce:
1.create cluster
2.try to update scheduling policy: 
/ovirt-engine/api/clusters/30376474-c62b-40b3-98a3-b052cc81daa0 body:<cluster>
        <thresholds low="20"/>

Actual results:
<scheduling_policy href="/ovirt-engine/api/schedulingpolicies/b4ed2332-a7ac-4d5f-9596-99a439cb2812" id="b4ed2332-a7ac-4d5f-9596-99a439cb2812">

Expected results:
cluster should be updated

Additional info:
attached engine logs (happened around ~18:19)

Comment 1 Red Hat Bugzilla Rules Engine 2016-05-09 05:45:25 UTC
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 2 Yaniv Lavi 2016-05-09 10:53:50 UTC
Moving to first RC, since things should not be targeted to second one at this point.

Comment 3 Juan Hernández 2016-05-09 11:28:43 UTC
Since version 3.5 of the engine scheduling policies are independent entities, which can (and should) be manipulated using the top level /schedulingpolicies collection. So the correct way to change the policy of a cluster is to lookup (or create) the policy using that collection, and then update the cluster using only the identifier of the policy:

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

However, we have been preserving the usage of an embedded policy for backwards compatibility. In version 4 of the engine this backwards compatibility treatment is triggered when receiving an embedded scheduling policy containing the "policy" attribute:

      <policy>power_saving</policy> <-- See that this uses "policy", not "name"

In version 3 of the engine we did the same for "name", and that was probably a bug. Anyhow, we will add support for that to version 4 of the engine as well.

Note also that when using this backwards compatibility mechanism the rest of the attributes of the scheduling policy, like the thresholds, are used to try to locate an existing scheduling policy that is compatible, so this may fail if there isn't such a policy.

I strongly advice to change the client to use the new (since 3.5) way to update the policy.

Comment 4 Artyom 2016-06-15 13:19:06 UTC
Checked on ovirt-engine-restapi-
PUT request to cluster under REST API V3
        <thresholds low="20"/>

Still not update scheduling policy:
<scheduling_policy href="/ovirt-engine/api/schedulingpolicies/b4ed2332-a7ac-4d5f-9596-99a439cb2812" id="b4ed2332-a7ac-4d5f-9596-99a439cb2812">

Comment 5 Red Hat Bugzilla Rules Engine 2016-06-15 13:19:12 UTC
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 6 Juan Hernández 2016-06-15 17:27:21 UTC
I have to insist that using <name>power_saving</name> means "use the power_saving policy defined in the top level /schedulingpolicies collection". The thresholds included in the request are then ignored. Backwards compatibility (with 3.4 and older) is triggered only when if you use <policy>power_saving</policy>. Please update your clients.

Comment 7 Artyom 2016-06-16 08:01:50 UTC
You right, with policy it works as expected:
        <thresholds low="20"/>

So you can move again but ON_QA and I will verify it(I also updated all our code to use scheduler policy id, so it must work fine from now)

Comment 8 Juan Hernández 2016-06-16 11:24:54 UTC
Great! Thanks Artyom, moving back to ON_QA then.

Comment 9 Artyom 2016-06-16 12:53:43 UTC
Verified on ovirt-engine-restapi-

Comment 10 Sandro Bonazzola 2016-07-05 07:58:30 UTC
oVirt 4.0.0 has been released, closing current release.

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