On 09/04/10 16:59 -0700, [email protected] 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 -- -------------------------------------------------------- Michal Fojtik, [email protected], +420 532 294 4307 Ruby / Ruby On Rails Developer Deltacloud API: http://deltacloud.org -------------------------------------------------------- _______________________________________________ deltacloud-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/deltacloud-devel
