Purpose

This is the functional specification for refactoring compute offering and disk offering

PR Reference

https://github.com/apache/cloudstack/pull/5008

Branch

4.17

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).

  1. Decoupling of compute offering and disk offering

    1. Compute offering and disk offering will not share the same UUID anymore. Both will have two different UUIDs to identify them separately

    2. Disk offering can be created individually and used for volumes (no change here)

    3. Any compute offering created will be linked to a disk offering (new column "disk_offering_id" is introduced in the "service_offering" table)

    4. To make backwards compatible, creating a regular compute offering also creates a disk offering. Created compute offering and disk offering will have different UUIDs and compute offering is linked to the created disk offering. This disk offering is marked as compute only (new column "compute_only" is introduced in the "disk_offering" table)

    5. While creating compute offering, instead of providing disk related details, an existing disk offering can be linked to the newly created compute offering

    6. While creating compute offering, instead of providing disk offering id, a new disk offering can be created on the fly and linked to the newly created compute offering


  2. Flexibility/strictness introduced in compute offering and disk offering

    1. A new parameter "diskofferingstrictness" is introduced for service offering to indicate the strictness of the disk offering associated 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 already created ROOT disk

    2. A new parameter "disksizestrictness" is introduced for disk offering 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

    3. A new global/zone level setting "match.storage.pool.tags.with.disk.offering" is introduced when true, volume's disk offering can be changed only with the matched storage tags. If false, then volume’s disk offering can be changed irresepective of existing storage tags.


  3. New API "changeOfferingForVolume" is introduced

    1. Disk offering of volume can be changed using this API

    2. During the change, volume will be resized if required based on the new disk offering

    3. During the change, volume will be auto migrated to a new compatible storage pool with new disk offering if required.

    4. If "disksizestrictness" on the existing disk offering is set to true, then the new disk offering should also have the same disk offering

    5. For root volume, if "diskofferingstrictness" is set to true in the compute offering then "changeOfferingForVolume" API fails for that volume since disk offering is strictly assigned to that root volume

  4. Existing API "resizeVolume" changes

    1. 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.

    2. Existing functionality is not changed to address backward compatibility. Users can still resize the volume by changing the disk offering.

  5. Existing API “migrateVolume” changes

    1. One can migrate a volume to the desired storage pool like before. The new change is about selecting the disk offering for replacement. When a storage pool is selected, disk offering for replacements will be listed based on the selected storage pool by filtering based on the storage tags (This list is controlled by the global setting “match.storage.pool.tags.with.disk.offering” explained in next section 6). This gives flexibility for the operator to be able to migrate the volume to any desired storage pool and also a easy way of selecting the appropriate disk offering corresponding to the storage pool. Previously we had to tweak database to point the volume to the appropriate disk offering after it has migrated to a storage pool.


  6. New global/zone level setting

"match.storage.pool.tags.with.disk.offering" (Boolean, default value true) - is introduced. when true, the volume's disk offering can be changed only with the matched storage tags. If false, then volume’s disk offering can be changed irrespective of existing storage tags.

Following are the cases that are controlled by this global setting explained per API.

    1. During changeOfferingForVolume API

      1. When “match.storage.pool.tags.with.disk.offering” is false

        1. List disk offerings irrespective of storage tags on the disk offering of volume

        2. Auto migrate to the storage pool (if required) based on the selected disk offering

      2. When “match.storage.pool.tags.with.disk.offering” is true

        1. List disk offerings only with the matching storage tags on the existing disk offering of volume

        2. Auto migrate to the storage pool (if required) based on the selected disk offering


    2. During migrateVolume API

      1. When “match.storage.pool.tags.with.disk.offering” is false

        1. List all suitable storage pools and admin/user should be able to migrate to any suitable storage pool

        2. 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.

      2. When “match.storage.pool.tags.with.disk.offering” is true

        1. List all suitable storage pools and admin/user should be able to migrate to any suitable storage pool

        2. 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 "service_offering" table following columns are copied from "disk_offering" table.

    • `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
    • `system_use`- is this service offering for system use only
    • `disk_offering_id` column in the "service_offering" table is populated with the same service offering id. This is because earlier same ID had been shared between both offerings.

  • 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"















    • If "Compute only Disk Offering" flag is turned OFF, then option is available to select an existing offering or create a new disk offering on the fly and select the newly created disk offering.















    • When "Add Disk Offering" button is clicked then a new "Add Disk Offering" wizard pops up.















    • A new flag "Disk Offering Strictness" (default OFF) is added in all cases as shown above.


  • Disk offering:

    • A new flag "Disk Size Strictness" (default OFF) is added.















  • 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.
















    • "Resize volume" wizard now only takes Size as a parameter




  • No labels