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:

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

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

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