Open Stack

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)


> 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.

-

Dimitri

On 05/05/14 20:18, "Chris Friesen" <chris.friesen at windriver.com> wrote:

>On 05/05/2014 11:40 AM, Solly Ross wrote:
>> One thing that I was discussing with @jaypipes and @dansmith over
>> on IRC was the possibility of breaking flavors down into separate
>> components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.
>> This way, you still get the control of the size of your building blocks
>> (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid
>> exponential flavor explosion by separating out the axes.
>
>I like this idea because it allows for greater flexibility, but I think
>we'd need to think carefully about how to expose it via horizon--maybe
>separate tabs within the overall "flavors" page?
>
>As a simplifying view you could keep the existing flavors which group
>all of them, while still allowing instances to specify each one
>separately if desired.
>
>Chris
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev