[openstack-dev] [heat] Can heat automatically create a flavor as part of stack creation?

Zane Bitter zbitter at redhat.com
Mon Feb 10 16:27:49 UTC 2014


On 09/02/14 03:09, Robert Collins wrote:
> In principle yes.
>
> You need:
>   - to write a module to orchestrate the nova flavor API.

https://wiki.openstack.org/wiki/Heat/Plugins

>   - to configure your policy rules in the cloud in question to let the
> heat engine user create flavors

Not quite. Heat does everything using the end-user's credentials. You 
should configure the cloud to allow the users you want to be able to 
create flavors to create them. (This makes sense if you think about it - 
if the heat-engine user did it you would have no granular control, and 
could only allow all users or no users to create flavors.)

> -Rob
>
> On 9 February 2014 20:49, ELISHA, Moshe (Moshe)
> <moshe.elisha at alcatel-lucent.com> wrote:
>> Hello,
>>
>>
>>
>> I am wondering if instead of being obligated to use an existing flavor, I
>> could declare a flavor (with its properties) inside Heat template and let
>> Heat create the flavor automatically?
>>
>> Similar to the ability to create networks as part of the template.

As Alex correctly points out in another reply, this is fairly unusual 
because normally you want the available flavors to be tightly controlled 
by the cloud operator.

There is some precedent for this in Heat - a couple of Neutron resources 
have properties to tie virtual network components to physical routers 
that are only available to admins. TBH I'm not thrilled about their 
existence though, until such time as we have some way to filter 
resources and properties based on what the user is permitted given their 
roles. If you were to write a plugin as Rob described above then I think 
it would belong in /contrib, not in the main tree.

In particular, this is not really something that is analogous to being 
able to creating (virtual) networks in the template, since that is 
something exposed to ordinary users via the Neutron API as a matter of 
course.

cheers,
Zane.



More information about the OpenStack-dev mailing list