Heat/Blueprints/dynamic-flavors

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:

parameters:
 instance_type:
   type: string
   description: Instance type for WordPress server
   default: m1.small
   constraints:
     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.

parameters:
   instance_ram:
      type: integer
      description: Memory size (in MB) for WordPress server
      default: 2048
      constraints:
        range: { min: 0 max: 16384 }
        description: must be non-negative number, up to 16384
    instance_vcpus:
      type: integer
      description: VCPUs for WordPress server
      default: 2
      constraints:
         allowed_values: [1, 2, 4, 8]
         description: must be one of 1, 2, 4, 8
    instance_disk:
       type: integer
       description: Disk size (in GB) for WordPress server
       default: 20
       constraints:
          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.

resources:
   wordpress_instance_type:
   type: OS::Nova::Flavor
   properties:
     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.

wordpress_instance:
   type: OS::Nova::Server
   properties:
     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.

References:

http://docs.openstack.org/trunk/openstack-ops/content/flavors.html

https://github.com/openstack/python-novaclient/blob/master/novaclient/v1_1/flavors.py