Bug 1334098

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.

Moving to first RC, since things should not be targeted to second one at this point.

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}
  <cluster>
    <scheduling_policy id="123..."/>
  </cluster>

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:

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

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.

Checked on ovirt-engine-restapi-4.0.0.4-0.1.el7ev.noarch
PUT request to cluster under REST API V3
<cluster>
    <scheduling_policy>
        <name>power_saving</name>
        <thresholds low="20"/>
    </scheduling_policy>
</cluster>

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

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 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.

You right, with policy it works as expected:
<cluster>
    <scheduling_policy>
        <policy>power_saving</policy>
        <thresholds low="20"/>
    </scheduling_policy>
</cluster>

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)

Great! Thanks Artyom, moving back to ON_QA then.

Verified on ovirt-engine-restapi-4.0.0.4-0.1.el7ev.noarch

oVirt 4.0.0 has been released, closing current release.