Open Stack

    >-----Original Message-----
    >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:
    ><snip>
    >> 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
    >already have.
    >
    >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
    >default domain.
    >
    >So for now, I'm -1 on adding a heat resource to create flavors, we should
    >fix the flavor scoping in Nova first IMO.
    >
    >Steve
    >_______________________________________________
    >
    >

Can we expect "role-based request scoping" for heat in icehouse-1 or near future? 

VijayKumar