On Mon, 2010-04-12 at 10:40 -0400, Scott Seago wrote: > [email protected] wrote: > > 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.
That's a good point. I agree that the client should have to match the arch on HWP with the arch on the image. In that case, the GoGrid driver should report arch ['i386', 'x86_64'] for memory sizes <= 4GB, and arch 'x86_64' for the ones above 4GB. > 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")? I look at the HWP as a best-effort attempt to report as much as possible about VM's that can be created. So, the properties are all independently optional, particularly since some backends (like OpenNebula) tell us nothing about any hardware properties. In practice, it's maybe not too much of a stretch to assume that arch is either i386 or x86_64 (until IBM starts selling zSeries slices in a cloud ;) I could change things that rather than not reporting any arch, I'd report the set of those two. > 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. Unfortunately, I don't think there's anything more elegant we can do automatically. If you have two backend accounts A and B, and HWP A1, A2, .., An for A and B1, B2, ..., Bm for B, a pool containing A and B should report all those HWP, plus all HWP Ai intersected with Bj for all i,j. In theory, you could allow user-defined HWP that cover more than the above, though you'll get funky placement behavior, i.e. depending on what concrete values you choose, your instance may only be able to run in A or B (or neither). In practice, that will become pretty unwieldy, and the best way out might be to ask the user what HWP they want to use, with some guidance on how the HWP they manufacture will affect VM placement. > > 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. Yes, the above means 'the instance is sized according to HWP m1-large, but has memory set to 15000MB'; if there are other non-fixed properties in m1-large, we are using the default value for them. > 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 Yes. > - 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 That's how I did it in my patches. > 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). True, though I agree that is still the cleanest way to model this. David _______________________________________________ deltacloud-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/deltacloud-devel
