DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Page History
Purpose
This is the functional specification for refactoring compute offering and disk offering
PR Reference
https://github.com/apache/cloudstack/pull/5008
Branch
4.1617
Introduction
Currently, our compute offerings and disk offerings are tightly coupled with respect to many aspects. For example, if a compute offering is created, a corresponding disk offering entry is also created with the same ID as the reference. Also creating compute offering takes few disk-related parameters which anyway goes to the corresponding disk offering only. I think this design was initially made to address compute offering for the root volume created from a template. Also changing the offering of a volume is tightly coupled with storage tags and has to be done in different APIs either migrateVolume or resizeVolume. Changing of disk offering should be seamless and should consider new storage tags, new size and place the volume in appropriate state as defined in disk offering.
Design
Following are changes made to decouple the compute offering and disk offering and keep meaningful linking between these two offerings keeping the backward compatibility. Also, there should be some flexibility and proper way of changing compute offerings and disk offerings of volumes (root/data).
...
During changeOfferingForVolume API
When “match.storage.pool.tags.with.disk.offering” is false
List disk offerings irrespective of storage tags on the disk offering of volume
Auto migrate to the storage pool (if required) based on the selected disk offering
When “match.storage.pool.tags.with.disk.offering” is true
List disk offerings only with the matching storage tags on the existing disk offering of volume
Auto migrate to the storage pool (if required) based on the selected disk offering
During migrateVolume API
When “match.storage.pool.tags.with.disk.offering” is false
List all suitable storage pools and admin/user should be able to migrate to any suitable storage pool
If admin/user wants to replace disk offering, list all disk offerings irrespective of storage tags on volume’s disk offering or selected storage pool.
When “match.storage.pool.tags.with.disk.offering” is true
List all suitable storage pools and admin/user should be able to migrate to any suitable storage pool
If admin/user wants to replace disk offering, list disk offerings only with the matching storage tags on the selected storage pool.
API changes
Following is the table with all new API and existing API parameter changes
Existing/New API | API name | Parameters |
Existing | createServiceOffering | diskofferingid (optional) (UUID) - to associate the disk offering (with one of the existing disk offerings) with the compute offering diskofferingstrictness - (optional, default value false) (boolean) - to indicate the strictness of the disk offering association with the compute offering. When set to true, override disk offering is not allowed on deploy VM and change disk offering is not allowed for the ROOT disk |
Existing | createDiskOffering | disksizestrictness (optional, default value false) (boolean) - to allow or disallow the resize operation on the disks created from this disk offering, if the flag is true then resize is not allowed |
Existing | resizeVolume | Existing parameter "size" is now used to change to resize volume directly without having to provide new disk offering. Previously this parameter is taken only when custom disk offering is provided. |
Existing | deployVirtualMachine | overridediskofferingid - the ID of the disk offering for the virtual machine to be used for root volume instead of the disk offering mapped in service offering. In case of virtual machine deploying from ISO, then the diskofferingid specified for root volume is ignored and uses this override disk offering id |
Existing | listDiskOffering | volumeid: id of the volume. When provided “disksizestrictness” flag added to the volume is used to list disk offering. If disk size strictness is true, then disk offerings with same size will be listed. This volume is also used to list disk offerings based on the storage tags of the existing disk offering of the volume, when the configuration parameter “match.storage.pool.tags.with.disk.offering” is true. storageid: id of the storage pool. When provided, storage tags on the storage pool will be considered to filter the disk offerings list, when the configuration parameter “match.storage.pool.tags.with.disk.offering” is true. Both volumeid and storageid cannot be provided at the same time. |
New | changeOfferingForVolume | id - id of the volume diskofferingid – id of the new disk offering to which offering has to be changed size, miniops, maxiops – details required if the provided offering is custom disk offering automigrate - flag for automatic migration of the volume with new disk offering whenever migration is required to apply the offering |
Database changes
Following table explains the new columns that are added to the database tables
Table name | New columns |
service_offering | Following are the new columns added to the table, these changes are mainly to decouple from disk offering. `uuid` - unique identifier `name` - name of the service offering `display_text` - display text of the service offering `unique_name` - unique name for system offerings `customized` - indicates if service offering is customizable or not `created` - date when service offering was created `removed` - date when service offering was removed `state` - state of service offering either Active or Inactive `disk_offering_strictness` - defines strict binding with disk offering or not `disk_offering_id` - ID of the disk offering to which service offering is linked to `system_use`- is this service offering for system use only |
disk_offering | `disk_size_strictness` - To allow or disallow the resize operation on the disks created from this offering `compute_only` - when set to 1, disk offering has one to one binding with compute offering and used for root disk only |
Following table explains the removed columns from the database tables
Table name | Removed columns |
disk_offering | `type` - This used to hold values "Service" or "Disk", this column is now changed to `compute_only` `system_use` - This is applicable only for service offering, so moved it to the service offering table |
vm_instance | `disk_offering_id` - this is a redundant column since root volume entry already holds the actual disk offering. Also, the disk_offering_id may not hold actual value if the disk offering is overridden during VM deployment. |
Upgrades
During management server upgrade, following are the changes that will be done. These changes makes sure old compute offerings and disk offerings works like before to keep backward compatibility.
...
For "disk_offering" table following are changes will be done during the upgrade
- `compute_only` - will be set to 1 for all disk offerings of type "Service".
- `disk_size_strictness` - will be set to 1 for all disk offerings which are compute only and disk size is defined.
UI changes
Compute offering:
Add compute offering wizard is updated by separating the compute fields and disk fields.
By default "Compute only Disk Offering" flag is turned ON. This indicates the existing behavior of creating compute offering and its corresponding disk offering entries at the same time. The created disk offering is marked as "compute_only"
...
Deploy VM wizard:
A new flag "Override Root Disk Offering" (default OFF) is added in Compute offering selection. This is editable and can override root disk offering only when selected Compute offering has "Disk Offering Strictness" set to false.
Volume:
A new action icon to trigger "changeOfferingForVolume" API. There is an option to select disk offering and an option to choose whether auto migrate is allowed or not.
...
Overview
Content Tools