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 has 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::DynamicFlavor 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::DynamicFlavor resource can use the above specified parameters to dynamically create a flavor from the values.
resources: wordpress_instance_type: type: OS::Nova::DynamicFlavor properties: 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.
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)