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: