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 dynamic_service_offering_details table. This table will contain the dynamic_offering id, VM id and a name,

value pair.

Different size of root disk when using same template.

Create a custom DiskOffering of type Root. currently we create a custom offering of type Disk. we will create a custom offering

with type Root to indicate the offering is for the root disks.  While creation of  a root volume from a template we check the 

disk offering, if user has passed a custom disk offering of type root we create a root volume of size mentioned in the DiskOffering 

Metering.

Every time a VM is launched or scaled we generate a usage event and populate the details in the dynamic_service_offering_details of the usage 

database. These dynamic_service_offering_details tables will contain the vmId, name value pair and a time stamp to indicate the date and time at

which the resource was allocated. 

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.

Changes to the APIs:

DeployVM API.  

parameters added. cpu, memory and cpuNumber. can be specified only when using dynamic service offering.

DAO changes.

Adding a new DAO to access the dynamic_offeirng_details table. 

Interface: 

getDetails(vmId)

findDetail(vmId, key)

persist(vmId,HashMap<Sting,String>

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 id of the corresponding entry in the dynamic_service_offering_details table in the vm_instance table and set the isdynamic flag to true.
• modify the method findById() to retrieve the dynamic_offering vo first if the isdynamic flag is true, and then use it to retrieve the corresponding service offering VO. populate the
  dynamic parameter details in the service offering Vo and return it. if not dynamic offering then return the service offering VO. (no need to access the dynamic_service_offering_details)
  

Changes to the ServiceOfferingVo.

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 additional parameters memory, cpu and cpunumber when using

dynamic service offering.

Upgrade:

No Upgrade changes.