[openstack-dev] [nova] [heat] Custom Flavor creation through Heat

Steven Hardy shardy at redhat.com
Thu Nov 14 12:32:56 UTC 2013


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



More information about the OpenStack-dev mailing list