Open Stack

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.

Best Regards,
Solly Ross

P.S. For people who use flavor names to convey information about the
workload, that probably a job better done by the VM tagging proposal
(https://review.openstack.org/#/c/91444/).

----- 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 1:20:09 PM
Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

I guess I need to describe the use-case first.
An example of Telco application is IP Multimedia Subsystem (IMS) [1],
which is a fairly complex beast. Each component of IMS can have very
different requirements on the computing resources. If we try to capture
everything in terms of flavors the list of flavors can grow very quickly
and still be specific to one single application. There¹s also many more
apps to deploy. Agree, one can say, just round to the best matching
flavor! Will work, but not the most efficient solution (a set of 4-5
global flavors will not provide the best fitting model for every VM we
need to spawn). For such applications a flavor is not the lowest level of
granularity. RAM, CPU, Disk is. Hence the question. In OpenStack, tenants
are bound to think in terms flavors. And if this model is the lowest level
of granularity, then dynamic creation of flavors actually supports this
model and allows non-trivial applications to use flavors (I guess this is
why this question had been raised last year by NSN). But, there are some
issues related to this :) and these issues I have written down in my first
mail.

Dimitri 

[1] http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem


On 05/05/14 17:23, "Solly Ross" <sross at redhat.com> wrote:

>Just to expand a bit on this, flavors are supposed to be the lowest level
>of granularity,
>and the general idea is to round to the nearest flavor (so if you have a
>VM that requires
>3GB of RAM, go with a 4GB flavor).  Hence, in my mind, it doesn't make
>any sense to create
>flavors on the fly; you should have enough flavors to suit your needs,
>but I can't really
>think of a situation where you'd need so much granularity that you'd need
>to create new
>flavors on the fly (assuming, of course, that you planned ahead and
>created enough flavors
>that you don't have VMs that are extremely over-allocated).
>
>Best Regards,
>Solly Ross
>
>----- Original Message -----
>From: "Serg Melikyan" <smelikyan at mirantis.com>
>To: "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev at lists.openstack.org>
>Sent: Monday, May 5, 2014 2:18:21 AM
>Subject: Re: [openstack-dev] [Nova][Heat] Custom Nova Flavor creation
>through Heat (pt.2)
>
>> Having project-scoped flavors will rid us of the identified issues, and
>>will allow a more fine-grained way of managing physical resources.
>
>Flavors concept was introduced in clouds to solve issue with effective
>physical resource usage: 8Gb physical memory can be effectively splitted
>to two m2.my_small with 4Gb RAM or to eight m1.my_tiny with 1 GB.
>
>Let's consider example when your cloud have only 2 compute nodes with 8GB
>RAM: 
>vm1 (m1.my_tiny) -> node1
>vm2 (m1.my_tiny) -> node1
>vm3 (m2.my_small) -> node1
>vm4 (m2.my_small) -> node2 (since we could not spawn on node1)
>
>This leaves ability to spawn predictable 2 VMs with m1.my_tiny flavor on
>node1, and 2 VMs m1.my_tiny or 1 VM m2.my_small on node2. If user has
>ability to create any flavor that he likes, he can create flavor like
>mx.my_flavor with 3GB of RAM that could not be spawned on node1 at all,
>and leaves 1GB under-used on node2 when spawned there. If you will
>multiply number of nodes to 100 or even 1000 (like some of the OpenStack
>deployments) you will have very big memory under-usage.
>
>Do we really need to have ability to allocate any number of physical
>resources for VM? If yes, I suggest to make two ways to define number of
>physical resource allocation for VMs: with flavors and dynamically.
>Leaving to cloud admins/owners to decide which way they prefer they cloud
>resources to be allocated. Since small clouds may prefer flavors, and big
>clouds may have dynamic resource allocation (impact from under-usage will
>be not so big). As transition plan project-scoped flavors may do the job.
>
>
>On Fri, May 2, 2014 at 5:35 PM, Dimitri Mazmanov <
>dimitri.mazmanov at ericsson.com > wrote:
>
>
>
>This topic has already been discussed last year and a use-case was
>described (see [1]).
>Here's a Heat blueprint for a new OS::Nova::Flavor resource: [2].
>Several issues have been brought up after posting my implementation for
>review [3], all related to how flavors are defined/implemented in nova:
>
>
>    * Only admin tenants can manage flavors due to the default admin rule
>in policy.json. 
>    * Per-stack flavor creation will pollute the global flavor list
>    * If two stacks create a flavor with the same name, collision will
>occur, which will lead to the following error: ERROR (Conflict): Flavor
>with name dupflavor already exists. (HTTP 409)
>These and the ones described by Steven Hardy in [4] are related to the
>flavor scoping in Nova.
>
>Is there any plan/discussion to allow project scoped flavors in nova,
>similar to the Steven¹s proposal for role-based scoping (see [4])?
>Currently the only purpose of the is_public flag is to hide the flavor
>from users without the admin role, but it¹s still visible in all
>projects. Any plan to change this?
>
>Having project-scoped flavors will rid us of the identified issues, and
>will allow a more fine-grained way of managing physical resources.
>
>Dimitri 
>
>[1] 
>http://lists.openstack.org/pipermail/openstack-dev/2013-November/018744.ht
>ml 
>[2] https://wiki.openstack.org/wiki/Heat/Blueprints/dynamic-flavors
>[3] https://review.openstack.org/#/c/90029
>[4] 
>http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.ht
>ml 
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>-- 
>Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
>http://mirantis.com | smelikyan at mirantis.com
>
>+7 (495) 640-4904, 0261
>+7 (903) 156-0836 
>
>_______________________________________________
>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