[openstack-dev] [nova] [heat] Custom Flavor creation through Heat
Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)
vijayakumar.kodam.ext at nsn.com
Thu Nov 21 12:13:54 UTC 2013
>From: ext Steven Hardy [mailto:shardy at redhat.com]
>Sent: Thursday, November 14, 2013 2:33 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat
>On Thu, Nov 14, 2013 at 08:22:57AM +0000, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) wrote:
>> Thanks Steve Baker for the information. I am also waiting to hear from Steve Hardy, if keystone trust system will fix the nova flavors admin privileges issue.
>So, basically, no. Trusts only allow you to delegate roles you already
>have, so if nova requires admin to create a flavor, and the user creating
>the heat stack doesn't have admin, then they can't create a flavor. Trusts
>won't solve this problem, they won't allow users to gain roles they don't
>As Clint has pointed out, if you control the OpenStack deployment, you are
>free to modify the policy for any API to suit your requirements - the
>policy provided by projects is hopefully a sane set of defaults, but the
>whole point of policy.json is that it's configurable.
>> One option to control the proliferation of nova flavors is to make them private to the tenant (using flavor-access?) who created them.
>> This provides the needed privacy so that others tenants cannot view them.
>This is the first step IMO - the nova flavors aren't scoped per tenant atm,
>which will be a big problem if you start creating loads of non-public
>flavors via stack templates.
>At the moment, you can specify --is-public false when creating a flavor,
>but this doesn't really mean that the flavor is private to the user, or
>tenant, it just means non-admin users can't see it AFAICT.
>So right now, if User1 in Tenant1 does:
>nova flavor-create User1Flavor auto 128 10 1 --is-public false
>Every user in every tenant will see it via tenant-list --all, if they have
>the admin role.
>This lack of proper role-based request scoping is an issue throughout
>OpenStack AFAICS, Heat included (I'm working on fixing it).
>Probably what we need is something like:
>- Normal user : Can create a private flavor in a tenant where they
> have the Member role (invisible to any other users)
>- Tenant Admin user : Can create public flavors in the tenants where they
> have the admin role (visible to all users in the tenant)
>- Domain admin user : Can create public flavors in the domains where they
> have the admin role (visible to all users in all tenants in that domain)
>Note the current "admin" user scope is like the last case, only for the
>So for now, I'm -1 on adding a heat resource to create flavors, we should
>fix the flavor scoping in Nova first IMO.
Can we expect "role-based request scoping" for heat in icehouse-1 or near future?
More information about the OpenStack-dev