[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