On 09/04/10 16:59 -0700, lutter@redhat.com wrote:
XML Representation
The XML representation for hardware profiles looks like
<hardware-profile href="http://localhost:3001/api/hardware_profiles/m1-large">
Why we use both hardware-profile and hardware_profile ? This must be handled by extra code in client/aggregator. For me, using hardware_profile also in URL is fine (same for storage(-_)snapshots/volumes).
<id>m1-large</id>
<property kind="range" name="memory" unit="MB" value="10240"> <param href="http://localhost:3001/api/instances" method="post" name="hwp_memory" operation="create"/> <range first="7680.0" last="15360"/> </property> <property kind="enum" name="storage" unit="GB" value="850"> <param href="http://localhost:3001/api/instances" method="post" name="hwp_storage" operation="create"/> <enum> <entry value="850"/> <entry value="1024"/> </enum> </property> <property kind="fixed" name="architecture" unit="label" value="x86_64"/> <property kind="fixed" name="cpu" unit="count" value="2"/> </hardware-profile>
That is: a hardware profile has a URL (the href attribute), an <id> child giving its name, and a list of <property> children. A property can be one of three kinds; all properties have a name, a (default) value, and a unit. We will try and not gratuitously change units, i.e. for now memory is always reported in MB. The three kinds of properties are
Looks clean for me ;)
- fixed: there's only one possible value for the property, the one in the value attribute
- range: the property can take on any number between the first and last number from the <range> child. The range is inclusive of the first and last value.
- enum: the property can take on one of a fixed set of values. The values are described inside an <enum> child, as the value attribute of the <entry> tags
Properties that can have more than one value, i.e. range and enum properties, also describe what operations are affected by them. Right now, this is only the create instance operation. The <param> child of the <property> element explains what parameter to pass to instance creation to change the value of that property.
Nice. We should consider creating a DTD or XScheme for all XMLs we produce and publish it on website (+ integrate it as part of tests)
Instance creation
When craeting an instance, you now have to pass the parameter hwp_id rather than flavor_id. The hwp_id has to be the <id> of an existing hardware profile. It is not necessary to pass any other hardware profile related parameters, since all proeprties have default values, and those are used for each property if only a hwp_id is given.
Optionally, additional parameters can be passed to instance creation to change some properties from their default value. With the above hardware profile, you could pass hwp_memory=15000 in addition to hwp_id=m1-large to get an instance with almost 15GB of memory.
Perfect, this will work nicely with those providers who allows to choose custom memory/storage values.
Instance representation
The XML for an instance now lists which properties had explicit values set when the instance was created; this is indicated in the XML as
<instance href="http://localhost:3001/api/instances/inst0"> <id>inst0</id> ... <hardware-profile href="http://localhost:3001/api/hardware_profiles/m1-large"> <id>m1-large</id> <property kind="fixed" name="memory" value="15000" unit="MB"/> </hardware-profile> ... </instance>
The 'instance profile' refers to an existing hardware profile by giving its URL and name, and uses <property> tags to show which properties have values differing from the hardware profile. The kind attribute on those tags is always 'fixed'.
Nice. Why isn't 'id' part of element btw? According to this whitepaper (http://www.ibm.com/developerworks/xml/library/x-eleatt.html) 'ID' is perfect candidate for element attribute.
Btw. ACK for all patches. Applied cleanely for me.
- Michal