Jump to: navigation, search


Fine-grained specification of resources for dynamic flavor creation in Heat

Currently the only way to specify what computational resources an instance shall have is through specifying an existing flavor. Example:

   type: string
   description: Instance type for WordPress server
   default: m1.small
     allowed_values: [m1.small, m1.medium, m1.large]
     description: must be one of m1.small, m1.medium or m1.large

This blueprint suggests using more fine-grained specification of computational resources – Memory_MB, VCPUs, Disk, etc.

      type: integer
      description: Memory size (in MB) for WordPress server
      default: 2048
        range: { min: 0 max: 16384 }
        description: must be non-negative number, up to 16384
      type: integer
      description: VCPUs for WordPress server
      default: 2
         allowed_values: [1, 2, 4, 8]
         description: must be one of 1, 2, 4, 8
       type: integer
       description: Disk size (in GB) for WordPress server
       default: 20
          range: { min: 0 max: 160 }
          description: must be non-negative number, up to 160 GB

This definition and usage of the parameters introduces a new resource type: OS::Nova::Flavor with the following properties:

Name Type Description
ram Integer Memory in MB for the flavor
vcpus Integer Number of VCPUs for the flavor
disk Integer Size of local disk in GB
name String Descriptive name of the flavor
flavor_id String ID for the flavor. Use the reserved value "auto" to have Nova generate a UUID for the flavor in cases where you cannot simply pass "None".
swap Integer Swap space in MB
ephemeral Integer Size of a secondary ephemeral data disk
rxtx_factor Number RX/TX factor
is_public Boolean Indicates whether the flavor is available to all users or private

A OS::Nova::Flavor resource can use the above specified parameters to dynamically create a flavor from the values.

   type: OS::Nova::Flavor
     name: x1.medium
     memory: { get_param: instance_ram }
     vcpus: { get_param: instance_vcpus}
     storage: {get_param: instance_disk}

Lastly, a OS::Nova:Server can refer to the worpress_instance_type resource when defining the flavor property.

   type: OS::Nova::Server
     image: { get_param: image_id }
     flavor: { get_resource: wordpress_instance_type }
     key_name: { get_param: key_name }

Use Cases:

An application may have custom requirement on the physical resources. In case of migration from one OpenStack cloud to another there’s no guarantee the default set of flavors is the same for both OpenStack clouds. Some applications may impose very specific constraints on the physical resources.

Possible Issues:

By default only the admin tenant can manage flavors because of the default policy in Nova:

 "compute_extension:flavormanage": "rule:admin_api"

To let the possibility to all tenants to create flavors, the rule must be replaced with the following:

 "compute_extension:flavormanage": ""

The following error occurs if the policy has not been correctly set:

 ERROR: Policy doesn't allow compute_extension:flavormanage to be performed. (HTTP 403)

Currently all nova flavors have a global scope, which leads to several issues:

  • Per-stack flavor creation will pollute the global flavor list.
  • If two stacks create a flavor with the same name collision will occur, which will lead to the following error:
 ERROR (Conflict): Flavor with name dupflavor already exists. (HTTP 409)

A possible workaround to these issues can be ability to create per-project nova flavors with the scope limited to the project.