<div dir="ltr"><div>><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">Having project-scoped flavors will rid us of the identified issues, and will allow a more fine-grained way of managing physical resources.</span></div>
<div><br></div><div>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. <br>
</div><div><br></div><div>Let's consider example when your cloud have only 2 compute nodes with 8GB RAM:</div><div>vm1 (m1.my_tiny) -> node1</div><div>vm2 (m1.my_tiny) -> node1 <br>vm3 (m2.my_small) -> node1</div>
<div>vm4 (m2.my_small) -> node2 (since we could not spawn on node1) <br></div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 5:35 PM, Dimitri Mazmanov <span dir="ltr"><<a href="mailto:dimitri.mazmanov@ericsson.com" target="_blank">dimitri.mazmanov@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-family:Calibri,sans-serif">
<div style="font-size:14px">This topic has already been discussed last year and a use-case was described (see [1]). </div>
<div style="font-size:14px">Here's a Heat blueprint for a new OS::Nova::Flavor resource: [2].</div>
<div style="font-size:14px">Several issues have been brought up after posting my implementation for review [3], all related to how flavors are defined/implemented in nova:</div>
<ul style="font-size:14px">
<li>Only admin tenants can manage flavors due to the default admin rule in policy.json. </li><li>Per-stack flavor creation will pollute the global flavor list</li><li>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)</li>
</ul>
<div style="font-size:14px">These and the ones described by Steven Hardy in [4] are related to the flavor scoping in Nova. </div>
<div style="font-size:14px"><br>
</div>
<div style="font-size:14px">Is there any plan/discussion to allow project scoped flavors in nova, similar to the Steven’s proposal for role-based scoping (see [4])?</div>
<div style="font-size:14px">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?</div>
<div style="font-size:14px"><br>
</div>
<div style="font-size:14px">Having project-scoped flavors will rid us of the identified issues, and will allow a more fine-grained way of managing physical resources.</div>
<div style="font-size:14px"><br>
</div>
<div style="font-size:14px">Dimitri</div>
<div style="font-size:14px"><br>
</div>
<div style="font-size:14px">[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/018744.html" target="_blank">
http://lists.openstack.org/pipermail/openstack-dev/2013-November/018744.html</a></div>
<div style="font-size:14px">[2] <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/dynamic-flavors" target="_blank">
https://wiki.openstack.org/wiki/Heat/Blueprints/dynamic-flavors</a> </div>
<div style="font-size:14px">[3] <a href="https://review.openstack.org/#/c/90029" target="_blank">
https://review.openstack.org/#/c/90029</a></div>
<div style="font-size:14px">[4] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html</a></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Serg Melikyan, Senior Software Engineer at Mirantis, Inc.<br></div><div><a href="http://mirantis.com/" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a><br>
<div><br>+7 (495) 640-4904, 0261</div><div>+7 (903) 156-0836</div></div></div>
</div>