Open Stack

> -----Original Message-----
> From: Solly Ross [mailto:sross at redhat.com]
> Sent: Tuesday, May 06, 2014 10:16 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation
> through Heat (pt.2)
> 
> For your first question, I'll probably create a BP sometime today.
> 
> For your second question, allowing tenants to create flavors
> prevents one of the main parts of the flavor idea from working --
> having flavors that nicely fit together to prevent "wasted" host
> resources.  For instance suppose the normal system flavors used
> memory in powers of 2GB (2, 4, 8, 16, 32).  Now suppose someone
> came in, created a private flavor that used 3GB of RAM.  We now
> have 1GB of RAM that can never be used, unless someone decides
> to come along and create a 1GB flavor (actually, since RAM has
> even more granularity than that, you could have someone specify
> that they wanted 1.34GB of RAM, for instance, and then you have
> all sorts of weird stuff going on).

Hi, Solly, I don't think the 3G is really that important since it has no alignment requirement and will not cause fragmentation, at least not that much to against the previous suggestion. After all, 3G + 3G + 2G can sit in a 8G host quite well, maybe a multiplier of 64M is fair enough and should work in large scale system.. Of course, 1.34G is strange for an engineer :)

--jyh

> 
> Best Regards,
> Solly Ross
> 
> ----- Original Message -----
> From: "Dimitri Mazmanov" <dimitri.mazmanov at ericsson.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Sent: Monday, May 5, 2014 3:40:08 PM
> Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation
> through Heat (pt.2)
> 
> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev