Open Stack

On 05/16/2013 12:21 PM, Michael J Fork wrote:
> Dan Smith <dms at danplanet.com> wrote on 05/15/2013 01:23:09 PM:
> 
>> From: Dan Smith <dms at danplanet.com>
>> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>,
>> Date: 05/15/2013 03:53 PM
>> Subject: Re: [openstack-dev] Dynamic Flavors Support
>>
>> > I'm also skeptical with the assertion in the blueprint that managing
>> > flavors is administratively intensive.
>>
>> I think that is probably true for Nova being applied to non-cloudy
>> deployment scenarios. However, that only points (IMHO) to why that
>> shouldn't be done in the first place.
> 
> 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.
>  
>> > Right now I'm -1 on this feature.  I'm open to being convinced,
>> > though, if others think it's useful and would like to argue their
>> > points.
>>
>> I definitely don't like the approach of creating actual flavors
>> dynamically, as is currently being proposed.
> 
> 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.

My statement that flavors are valuable should not be confused as me
suggesting that creating them dynamically is a good solution for this
use case.

>> If I recall correctly, part of the reason we (I) made the move to
>> storing flavor information in system_metadata was so that we could have
>> fine-grained resizes, if desired. Assuming a deployer wanted to sell
>> small upgrades, like buying more memory without needing more disk
>> space, etc.
>>
>> In my opinion, it would be completely reasonable to support that via an
>> API extension which would modify the instance's private flavor
>> information and then trigger a resize (which should do the right thing
>> today, as far as I know). I also believe that billing would be handled
>> correctly, assuming the instance usage stuff takes the flavor
>> information from the instance's private copy (which I think it does).
>>
>> That gives us the flexibility do what Michael wants (I think), without
>> needing to expose it via the (overly-complex) dynamically-created
>> flavors approach.
> 
> 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).

Dan makes a good point about how the code works and I think his
suggestion is very reasonable.  What's wrong with it?  You didn't really
say, other than just standing firm to your original proposal ...

-- 
Russell Bryant