Open Stack

On Mon, May 05, 2014 at 07:40:08PM +0000, Dimitri Mazmanov wrote:
> This is good! Is there a blueprint describing this idea? Or any plans
> describing it in a blueprint?
> Would happily share the work.
> 
> Should we mix it with flavors in horizon though? I¹m thinking of having a
> separate ³Resources² page,
> wherein the user can ³define² resources. I¹m not a UX expert though.
> 
> But let me come back to the project-scoped flavor creation issues.
> Why do you think it¹s such a bad idea to let tenants create flavors for
> their project specific needs?
> 
> I¹ll refer again to the Steve Hardy¹s proposal:
> - 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)

To clarify, that wasn't a "proposal" as such, it was merely a suggested
specification of a Nova interface that could work, if we want to implement
a Nova flavor resource in Heat which will actually be useful to a
reasonable subset of our users.

Here's the thread reference:

http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html

I was responding to a question asking if trusts would somehow fix this
problem, to which the answer is no, and describing challenges faced by
anyone trying to implement custom flavor creation through Heat, because
the Nova API creates global objects, not objects scoped to a project.

Essentially I find the discussion of how to do this via Heat kinda
backwards, we should first figure out how to solve this problem with Nova
directly, then exposing whatever Nova interface solves the problem via Heat
becomes trivial.

> > If you actually have 64 flavors, though, and it's overwhelming
> > your users, ...
> 
> The users won¹t see all 64 flavor, only those they have defined and public.

Well, that's the whole problem - private flavors aren't really private, and
if a user defines a flavor, all other users *will* see it (if they have the
admin role in any project)

See my link above, --is-public false doesn't do what you think it does.

Steve