Hardware profiles

Each deltacloud driver exposes a fixed set of hardware profiles (HWP). HWPs replace the original 'flavor' concept.

A hardware profile consists of an architecture (e.g. i386 vs x86_64), number of CPUs, memory size and storage size.

hwp_name is accepted as a parameter when POSTing to the instances collection.

A profile can define some of its properties as a range or an enum. In these cases, the client may choose from the range or enum when creating an instance. The client specifies its choice using a parameter in the POST and the available parameters are advertised in hardware profile properties using the <param/> element.

There is the notion of a default hardware profile if the user doesn't specify any when creating an instance. The default profile is chosen by using the first profile which matches the image's architecture.

Some driver defines profiles statically e.g.:

  define_hardware_profile('m1.small') do
    cpu                1
    memory             1.7 * 1024
    storage            160
    architecture       'i386'
  end

An example of using ranges and enums:

  define_hardware_profile('m1-large') do
    cpu                2
    memory           (7.5*1024 .. 15*1024), :default => 10 * 1024
    storage          [ 850, 1024 ]
    architecture     'x86_64'
  end

You can also define a hardware profile with no properties:

  define_hardware_profile 'opaque'

The rackspace driver defines profiles dynamically by querying for available flavors:

  results = racks.list_flavors.map do |flav|
    HardwareProfile.new(flav["id"].to_s) do
      architecture 'x86_64'
      memory flav["ram"].to_i
      storage flav["disk"].to_i
    end

The terremark driver makes all properties configurable with a single profile:

  define_hardware_profile 'default' do
    cpu   [1,2,4,8]
    memory  [512, 1024, 2048, 4096, 8192]
    storage (1..500).to_a
 end

RHEV-M Driver

There are a few different routes we could take:

1. Statically define a small fixed set of profiles (e.g. small, medium, large) with a range/enum for each property. The different profiles would basically just serve to give useful defaults
2. Allow the profiles to be managed by the administrator with e.g. a simple config file. Preferably, though, there would be an admin API for it too
3. RHEV-M templates aren't just VM images - they also have memory, storage and CPU properties. We could allow RHEV-M admins to define a set of templates that would be discoverable by the deltacloud driver (e.g. by using a standard naming scheme or applying a standard tag to each of these templates). The driver would advertise each of these templates as a hardware profile.