<html><body>
<p><tt><font size="2">Russell Bryant <rbryant@redhat.com> wrote on 05/16/2013 04:05:59 PM:<br>
> On 05/16/2013 12:21 PM, Michael J Fork wrote:<br>
> > Dan Smith <dms@danplanet.com> wrote on 05/15/2013 01:23:09 PM:<br>
> >><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>
> > <br>
> > I disagree that the solution is overly-complex for a deployer or user of<br>
> > the APIs (my primary focus). The access to APIs would be consistent<br>
> > whether you used a flavorRef or flavor and every instance would have a<br>
> > flavor reference assigned that accurately represented resource usage<br>
> > (something expected by virtually every application written to an IaaS<br>
> > API today).<br>
> <br>
> Dan makes a good point about how the code works and I think his<br>
> suggestion is very reasonable. What's wrong with it? You didn't really<br>
> say, other than just standing firm to your original proposal ...<br>
></font></tt><br>
<br>
<tt><font size="2">My understanding of Dan's proposal is that the flavor would represent the starting point and, after any fine-grained resize, it would no longer represent actual usage. To get at actual usage, you would need to ignore the flavor information on the server response and directly use individual values (vcpus, ram, disk, and exra_specs). If this is true, I consider this a step backwards in user experience: having a flavor (or similar concept) to represent allocation is a generally accepted practice used across most infrastructure offerings. Retaining that user experience is what drove the original design. </font></tt><br>
<br>
<tt><font size="2">As part of retaining the experience, auto-created flavors would be marked as private and therefore not shown to users when listing flavors. However, if an API user references one directly by ID in a create server/resize/show request it would be permissible - e.g. they are duplicating an existing server, query the flavor, then use in the subsequent create server.</font></tt><br>
<tt><font size="2"> <br>
> -- <br>
> Russell Bryant<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></body></html>