Versions Compared

Old Version 4

changes.mady.by.user Unknown User (harikrishna)

Saved on

compared with

New Version 5

changes.mady.by.user Unknown User (harikrishna)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Purpose

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

PR Reference

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

Branch

4.16

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

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"

...