>-----Original Message----- >From: ext Steven Hardy [mailto:sha...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev