<html><body>
<p><tt><font size="2">Dan Smith <dms@danplanet.com> wrote on 05/15/2013 01:23:09 PM:<br>
<br>
> From: Dan Smith <dms@danplanet.com></font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font></tt><br>
<tt><font size="2">> Date: 05/15/2013 03:53 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] Dynamic Flavors Support</font></tt><br>
<tt><font size="2">> <br>
> > I'm also skeptical with the assertion in the blueprint that managing<br>
> > flavors is administratively intensive.<br>
> <br>
> I think that is probably true for Nova being applied to non-cloudy<br>
> deployment scenarios. However, that only points (IMHO) to why that<br>
> shouldn't be done in the first place.</font></tt><br>
<br>
<tt><font size="2">Agree with this statement when cloud = IaaS, but not when viewing cloud as more of a platform to build scalable applications to build on. In a cloud where end-user cost is based on resource allocation (e.g. virtually every public cloud), the user is forced to go to a bigger VM because higher allocation rations can be driven using cookie cutter sizes. In an installation measured on utilization, we do not want to force a user to allocate an additional CPU it doesn't need.</font></tt><br>
<tt><font size="2"> <br>
> > Right now I'm -1 on this feature. I'm open to being convinced,<br>
> > though, if others think it's useful and would like to argue their<br>
> > points.<br>
> <br>
> I definitely don't like the approach of creating actual flavors<br>
> dynamically, as is currently being proposed.<br>
</font></tt><br>
<tt><font size="2">As Russell stated in an earlier mail, flavors serve a valuable purpose; I believe we must maintain the existing relationship between flavors and instances where every instance has a flavor that accurately represents the usage.</font></tt><br>
<tt><font size="2"> <br>
> If I recall correctly, part of the reason we (I) made the move to<br>
> storing flavor information in system_metadata was so that we could have<br>
> fine-grained resizes, if desired. Assuming a deployer wanted to sell<br>
> small upgrades, like buying more memory without needing more disk<br>
> space, etc.<br>
> <br>
> In my opinion, it would be completely reasonable to support that via an<br>
> API extension which would modify the instance's private flavor<br>
> information and then trigger a resize (which should do the right thing<br>
> today, as far as I know). I also believe that billing would be handled<br>
> correctly, assuming the instance usage stuff takes the flavor<br>
> information from the instance's private copy (which I think it does).<br>
> <br>
> That gives us the flexibility do what Michael wants (I think), without<br>
> needing to expose it via the (overly-complex) dynamically-created<br>
> flavors approach.<br>
</font></tt><br>
<tt><font size="2">I disagree that the solution is overly-complex for a deployer or user of the APIs (my primary focus). The access to APIs would be consistent whether you used a flavorRef or flavor and every instance would have a flavor reference assigned that accurately represented resource usage (something expected by virtually every application written to an IaaS API today).</font></tt><br>
<tt><font size="2"><br>
> --Dan<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt><br>
<font size="2" face="sans-serif">Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Architect, OpenStack Development<br>
IBM Systems & Technology Group</font><br>
</body></html>