...
3.) Metering of these dynamically assigned resources for usage details.
Design details:
Dynamic Offerings.
...
storing these values in the dynamicuservm_service_offering_details table. This table will contain the dynamic_offering id, VM 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
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 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
. 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 databasewhich the resource was allocated.
In case of metering for custom root disk we 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 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 Usage_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.
...
...
changing the return types to objects to indicate that they can be null.
Things Open to discussion.
...
need to call the api deploy vm with the additional parameters memory, cpu and cpunumber new parameter called custom parameters when using
dynamic service offering.
Upgrade:
No Upgrade changes. .
Limitations:
Note the custom root disk size support will be available in next release.