Dynamic Compute Offering FS

Introduction:

Currently in cloudstack we need to associate every vm with a service offering and also we cannot specify the size of the root disk when using templates i.e. we

cannot specify different size of root disks while using the same template.

This  feature  will allow VM creation without the need to choose the fixed amount of compute mentioned in the pre created service offerings. 

Also allow users to specify the size of the root disk while using templates. users can specify their own compute requirements at the time of VM 

creation, if they do not want to use fixed values in the pre created service offerings. This is similar to the custom disk offering.

Requirements:

This feature should allow

1.)  Admins to create service offerings by marking cpu, memory and root disk as  dynamic parameters. 

2.)  users to use this dynamic service offering to specify the  memory, cpu and root disk at the time of VM creation or upgrade.

3.)  Metering of these dynamically assigned resources for usage details.

Design details:

Dynamic Offerings.

We plan to implement this feature by addition of  dynamic service offerings. The dynamic service offering is 

same as the normal service offering except that the values of the dynamic parameters will be set to zeros.  These dynamic

service offerings can be used to deploy VM by specifying custom values for the dynamic parameters. Any parameter in the 

service offering which is not specified while creating will be treated as dynamic parameter. As of now we will allow only 

memory, cpu and cpuNumber to be specified as empty parameters in other words as dynamic parameters.

Tracking of resources allocated to VMs when using Dynamic Compute Offering:

Each of the dynamic service offering can be used to deploy VMs while specifying different values of dynamic parameters.

As a result of this each service offering is associated with different values of dynamic parameters (like cpu and memory). We keep track of this by

storing these values in the uservm_details table. This table will contain the  VM id and a name,

value pair.

Different size of root disk when using same template.

The rootdisk size can be specified using a map of custom parameters. 

Metering.

Every time a VM is launched or scaled we generate a usage event. The usage event has a serviceOffeirng ID. If the VM is created form a dynamic service offering we populate 

the id of the dynamic service offering and the value of dynamic parameters in the Usage_details table. The usage server will have to read this table to populate the usage_vm_instance

table in the usage database. we will add new columns cpu, memory etc to the usage_vm_instance table of the usage database. 

In case of metering for custom root disk we need not  make any change. For metering we can read the size of the root disk form the usage event.

Global min and max value for the dynamically allocated values.

In order to give some control to the admin to enforce the maximum and min value of dynamic parameter  that can be set by a user, we 

add global config variables to specify the min and max values. At the time of VM launch we check if the dynamic parameters are within the 

min and max values specified by the admin. 

Changes to the APIs:

DeployVM , ScaleVM , ScaleSystemVM , UpgradeVM, UpgradeSysytemVM API.  

The change is same in all the APIs. we added a map of  custom parameters called customparameters. all the custom values need to be specified using this map parameter.

presently on cpu cores, memory and cpu speed can be specified when using dynamic service offering.

DAO changes.

Adding a new DAO  Usage_details_table. 

Changes to the ServiceOfferingDao.

Currently in cloudstack we use the serviceofferig interface to access the cpu, memory and number of cores in a service offering.

The serviceoffringVO is retrevied by using the method findbyId() throughout the cloudstack. with addition of dynamic service offering

this will return a VO with null values for the dynamic parameters.  So we intend to modify the current code in the following way.

• if the offering is dynamic store the custom parameter values in the uservmdetails table. when trying to retrieve a dynamic offering we populate the custom values after reading form the uservmdetails and retun the serviceofferng.

changing the return types to objects to indicate that they can be null.

Things Open to discussion.

Why do we need multiple dynamic service offerings ?

UI Changes:

 Allow a choosing  a custom value for memory, cpu and cpu cores while using dynamic offering. 

 need to call the api deploy vm with the new parameter called custom parameters when using

dynamic service offering.

Upgrade:

No Upgrade changes.

Limitations:

• we restrict the customOffering not to allow specifying of one or more  but not all of the cup, cpuSpeed and memory as custom.
  if a offering is custom it means all the parameters i.e. cpu cores, memory and cpuSpeed are custom.

• The dynamic compute offering is not applicable to system service offerings.

Note the custom root disk size support  will be available in next release.