<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 17, 2013, at 1:20 PM, Michael J Fork <<a href="mailto:mjfork@us.ibm.com">mjfork@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><p><tt><font size="2">Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote on 05/16/2013 11:38:46 PM:<br>
<br>
> From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>></font></tt><br>
<tt><font size="2">> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>, </font></tt><br>
<tt><font size="2">> Date: 05/16/2013 11:42 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] Dynamic Flavors Support</font></tt><br>
<tt><font size="2">> <br>
> On 05/16/2013 10:16 PM, Dan Smith wrote:<br>
> > I think that the general consensus is that the notion of dynamic<br>
> > flavors is an unfavorable approach. Since we happen to be having this<br>
> > discussion while an API redesign is happening, I'd say the more<br>
> > productive path forward is to figure out how we want per-instance usage<br>
> > to be exposed which makes sense both with and without fine-grained<br>
> > resource tweaks. Perhaps a flavorRef is the wrong way.<br>
> > <br>
> > Right now, if you create an instance from flavor 1, then change the<br>
> > parameters of flavor 1, the flavorRef will be wrong anyway. Before I<br>
> > moved instance_type information to system_metadata, doing that would<br>
> > even cause billing stuff to be incorrect. Lets figure out how to<br>
> > represent the actual instance parameters in APIv3, which I think will<br>
> > serve everyone's needs.<br>
> <br>
> Sounds like a good plan to me.<br>
> <br>
> As you said, given the timing with the v3 API work, we have an<br>
> opportunity to do some refactoring here and do it "right".<br>
</font></tt><br>
<tt><font size="2">Before we make any substantial changes, should we query the user-committee (or similar group) to get feedback on the impact to operators and users of the API? I think the basic question here is do we retain the 1:1 linkage between Server and Flavor where a Server links to a Flavor that can be referenced by ID or do we move to a model where Flavor is the initial template and post-provision the allocation is through a data structure that is essentially the content of a Flavor today (but without the </font></tt><tt><font size="2">referenceable </font></tt><tt><font size="2">ID).</font></tt><br></p></div></blockquote><div><br></div><div>There clearly needs to be a way to get this information for an instance. One possibility is simply to do a GET flavors/<instance-uuid> which would return the exact same information as a regular flavors request (w/o a flavor name i suppose). This should make it easy for end users who were depending on the existing flavor-ref idea. This is sort of a hybrid approach, where internally we don't have dynamic flavors but we provide a "compatibility" api for users who expect them to be separate. The other possibility is to add the entire flavor object to the instance get. This actually gives us a nice path forward in regards to v2/v3 as well where v2 could keep the flavor-ref and use the above method for retrieving information and v3 could abandon flavor-ref for full flavor data in instance get.</div><div><br></div><div>Vish</div><br><blockquote type="cite"><div><p>
<br>
<tt><font size="2">> -- <br>
> Russell Bryant<br>
> <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">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>
</p></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>