lutter@redhat.com wrote:
This series of patches adds support for hardware profiles to Deltacloud core. Hardware profiles describe how instances can be sized, and are more general than the old flavors, in that each property can either be a fixed value, a predefined enumeration of values, or a range of values.
To try these patches with the mock driver, you need to stop your server, rm -rf the mock storage root (usually /var/tmp/deltacloud-core-$USER), and start the server again once you have the patches applied.
Even if you don't try these patches, I'd highly appreciate feedback on all this, especially the XML representation of hardware profiles.
Although I haven't tested any of this, I looked over all the patches. I had a couple questions on specific patches, and some inline questions/comments below, but overall this looks good to me. I think I have most of what I need to start implementing this on the aggregator side now.
XML Representation
The XML representation for hardware profiles looks like
<hardware-profile href="http://localhost:3001/api/hardware_profiles/m1-large"> <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"/>
How do architecture values for HWP and image (and instance?) interact. With GoGrid, there is no HWP arch, but other drivers include it. I'm assuming that, if present, we've got to match up arch for HWP, image, instance, etc. Is there anything else to worry about here? Is architecture the only optional parameter? In the 'opaque' case (such as OpenNebula) all params are blank -- are the HWP parameters independently optional, or do we have distinct allowable sets of params (i.e. "specify all", "specify none", "specify all but arch")?
In the aggregator model, with the old flavor model, I created a set of mappings from "front end" (i.e. aggregator-facing) profiles to "back end" profiles, split by architecture. So you might have a front end "small" profile that maps to one HWP for back end account foo, arch x86_64, and another profile for account foo, arch i386, and a similar set for each other back end account. You might have more than one for a given arch and account, since there might not be a clear one-to-one overlap. With architecture as optional, I guess I could keep that same model but allowing arch to be empty for the back end profiles.
More generally, as we've previously discussed, the new HWP model with ranges, etc may be more difficult to handle in the aggregator-to-provider mappings. We still need a way to allow the aggregator user to choose a single hardware profile for an aggregator instance (since we're specifying instances via the deltacloud API), and we need a way for this profile to map to multiple back end accounts (since a single instance start request could run on any number of back end accounts depending on image and realm selection)
<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
- 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.
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.
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>
From looking at patches, it sounds like the above specifies two things: 1) a reference to the existing HWP m1-large 2) the definition of an internal (non-shared) instance profile object that defines memory but leaves everything else blank.
So I had a couple questions here: - The "effective" HWP for an instance (i.e. its actual resource consumption) is determined by taking the HWP and replacing the default values with any values specified in the instance profile - This is more of an aggregator modeling question, but I've got a few options for modeling this in the aggregator DB: 1) explicit instance profile object with the overridden params and a reference to the HWP in the instance profile. replace HWP ref in instance with an instance profile ref 2) explicit instance profile object as above, but keep the HWP ref in the instance def (alongside the instance profile ref) 3) add individual cpu_override, ram_override, etc params to instance instead of creating a separate instance_profile object.
For the aggregator modeling bit, 1) seems to be the cleanest -- it also provides a convenient place to put the business logic that merges the overrides with the HWP itself, but it requires an extra join to get at the HWP (and requires instance profile objects even when we're not overriding anything).
Scott
...</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'.
Drivers
I've tested this pretty extensively, and at least for the EC2, Rackspace, and GoGrid drivers everything seems to work. I don't have a way to test the drivers for RimuHosting, RHEV-M, or OpenNebula. I know that these drivers need work, and would appreciate it if others could help out.
Patch series
The first 3 patches are minor cleanups, not directly related to hardware profiles. Patches 4-7 mutate hardware profiles to what we need, and add XML output for them. Patches 8-24 are concerned with integrating hardware profiles into the existing server and the drivers. Patch 25 removes any support with flavors - if you need to use flavors for a transitional period, that should be possible solely by not applying patch 25. _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel