Open Stack

On May 17, 2013, at 1:20 PM, Michael J Fork <mjfork at us.ibm.com> wrote:

> Russell Bryant <rbryant at redhat.com> wrote on 05/16/2013 11:38:46 PM:
> 
> > From: Russell Bryant <rbryant at redhat.com>
> > To: openstack-dev at lists.openstack.org, 
> > Date: 05/16/2013 11:42 PM
> > Subject: Re: [openstack-dev] Dynamic Flavors Support
> > 
> > On 05/16/2013 10:16 PM, Dan Smith wrote:
> > > I think that the general consensus is that the notion of dynamic
> > > flavors is an unfavorable approach. Since we happen to be having this
> > > discussion while an API redesign is happening, I'd say the more
> > > productive path forward is to figure out how we want per-instance usage
> > > to be exposed which makes sense both with and without fine-grained
> > > resource tweaks. Perhaps a flavorRef is the wrong way.
> > > 
> > > Right now, if you create an instance from flavor 1, then change the
> > > parameters of flavor 1, the flavorRef will be wrong anyway. Before I
> > > moved instance_type information to system_metadata, doing that would
> > > even cause billing stuff to be incorrect. Lets figure out how to
> > > represent the actual instance parameters in APIv3, which I think will
> > > serve everyone's needs.
> > 
> > Sounds like a good plan to me.
> > 
> > As you said, given the timing with the v3 API work, we have an
> > opportunity to do some refactoring here and do it "right".
> 
> 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 referenceable ID).
> 

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.

Vish

> 
> > -- 
> > Russell Bryant
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> Michael
> 
> -------------------------------------------------
> Michael Fork
> Architect, OpenStack Development
> IBM Systems & Technology Group
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/4f0a6775/attachment.html>