Artyom, what version of the engine are you using exactly?

Version-Release number of selected component (if applicable):
ovirt-engine-3.4.0-0.11.beta3.el6.noarch

Doron, I think this doesn't justify blocking the 3.4 release, but is worth fixing for 3.4.1. Do you agree?

Regarding representation I suggest the following:

  <scheduling_policy>
    <policy>vm_evenly_distributed</policy>
    <high_vm_count>...</high_vm_count>
    <migration_threshold>...</migration_threshold>
    <spm_vm_grace>...</spm_vm_grace>
  </scheduling_policy>

It would be good to use this same representation for the other policies.

Juan, 

Currently the rest expose policy and thresholds (high, low, duration).
We need to expose the custom properties sheet in scheduling_policy, to include all parameters and future ones:

    <scheduling_policy>
        <policy>evenly_distributed</policy>
        <thresholds high="90" duration="120"/>
        <custom_properties> <!-- I prefer to leave it with the common name -->
                <custom_property name="HighUtilization" value="90"/>
                <custom_property name="CpuOverCommitDurationMinutes" value="2"/> <!-- value is in minutes, whereas duration is in seconds -->
        </custom_properties>
    </scheduling_policy>

Note that there is display duplication of high, low and duration in the custom properties sheet (because of backward compatibility).


Are you okay with the proposed^ solution? 

Have a nice day,
Gilad.

I prefer if we avoid using the custom_property element, as it uses attributes instead of nested elements, and that means that it is difficult to extend and it is difficult to use values that aren't short strings. Please create a new "properties" element, like this:

  <xs:complexType name="Property">
    <xs:sequence>
      <xs:element name="name" type="xs:string" minOccurs="1" maxOccurs="1"/>
      <xs:element name="value" type="xs:string" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="properties" type="Properties"/>

  <xs:complexType name="Properties">
    <xs:sequence>
      <xs:element ref="property" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

Then use it, so that the representation will be as follows:

  <scheduling_policy>
    <policy>evenly_distributed</policy>
    <thresholds high="90" duration="120"/>
    <properties>
      <property>
        <name>HighUtilization</name>
        <value>90</value>
      </property>
      <property>
        <name>CpuOverCommitDurationMinutes</name>
        <value>2</value>
      </property>
    </properties>
  </scheduling_policy>

I'd appreciate if the introduction of the "properties" element can be done in a separate patch.

Also, please open a bug targeted for 4.0, so that we remember remove the "thresholds" element. Put [DEPRECATION] as a prefix to the subject.

Thanks Juan for the elaborate explanation. giving it some more thought, we can consider not adding another 'Property' element, and simply reuse the existing one, expanding it with name and value tags:

        <custom_properties>
                <custom_property name="abd" value="1"/>
                <custom_property name="def" value="2">
                                <name>def1</name>
                                <value>2.1</value>
                </custom_property>
                <custom_property>
                                <name>ghi</name>
                                <value>3</value>
                </custom_property>
        </custom_properties>

in the example^^ all inputs are valid.
for 'def' custom property, 'def1' (val 2.1) will be applied -> tags will override attributes.

this will keep the REST unified, and later on we can deprecate the attributes (or not.. it doesn't really matter).

what do you say?

Thanks, and sorry for the nagging :)

The problem with this is that having a "name" attribute and a "name" inner element generates a conflict in the Java and Python code generators that we use for the API itself and for the SDKs.

*** Bug 1073764 has been marked as a duplicate of this bug. ***

This is an automated message.

oVirt 3.4.1 has been released.
This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.

Verified on ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch

oVirt 3.5 has been released and should include the fix for this issue.