Open Stack

Follow-up thought:

> This concept has never been questioned anywhere I can search, so I have a
feeling I'm missing something big here. Maybe other ways are too
complicated to implement?

This topic does get brought up from time to time, but in different areas
under different names. Off of the top of my head, a past discussion about
quota management and how one could limit the amount of SSD disk space a
user could use while giving them larger access to a spindle disk.

Being able to manage different characteristics about a resource (disk size
vs disk IOPS) is a complicated thing to do and it's certainly not a solved
problem. I don't want to say something like "flavors are just the accepted
norm" because that would be doing them a huge injustice, but I did want to
follow-up and say that you're not alone if you've hit issues with the way
resources are bundled. :)

On Wed, Mar 15, 2017 at 10:31 PM, Joe Topjian <joe at topjian.net> wrote:

> Another benefit of flavors is that they provide ease of use. While there
> are users who are confident enough to spec out each instance they launch, I
> work with a lot of users who would feel overwhelmed if they had to do this.
> Providing a set of recommended instance specs can go a long way to lowering
> the barrier of usage.
>
> On Wed, Mar 15, 2017 at 10:19 PM, Mike Lowe <jomlowe at iu.edu> wrote:
>
>> How would you account for heterogeneous node types? Flavors by convention
>> put the hardware generation in the name as the digit.
>>
>> Sent from my iPad
>>
>> On Mar 15, 2017, at 11:42 PM, Kris G. Lindgren <klindgren at godaddy.com>
>> wrote:
>>
>> So how do you bill for someone when you have a 24 core, 256GB ram, with
>> 3TB of disk machine - and someone creates a 1 core, 512MB ram, 2.9TB disk –
>> flavor?  Are you going to charge them same amount as if they created a 24
>> core, 250GB instances with 1TB of disk?  Because both of those flavors make
>> it practically impossible to use that hardware for another VM.  Thus, to
>> you they have exactly the same cost.
>>
>>
>>
>> With free-for all flavor sizes your bin packing goes to shit and you are
>> left with inefficiently used hardware.  With free for all flavor sizes how
>> can you make sure that your large ram instances go to sku’s optimized to
>> handle those large ram VM’s?
>>
>>
>>
>> ___________________________________________________________________
>>
>> Kris Lindgren
>>
>> Senior Linux Systems Engineer
>>
>> GoDaddy
>>
>>
>>
>> *From: *Matthew Kaufman <mkfmncom at gmail.com>
>> *Date: *Wednesday, March 15, 2017 at 5:42 PM
>> *To: *"Fox, Kevin M" <Kevin.Fox at pnnl.gov>
>> *Cc: *OpenStack Operators <openstack-operators at lists.openstack.org>
>> *Subject: *Re: [Openstack-operators] Flavors
>>
>>
>>
>> Screw the short answer -- that is annoying to read, and it doesn't
>> simplify BILLING from a CapEx/OpEx perspective, so please - wtf?
>>
>> Anyway, Vladimir - I love your question and have always wanted the same
>> thing.
>>
>>
>>
>> On Wed, Mar 15, 2017 at 6:10 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>>
>> I think the really short answer is something like: It greatly simplifies
>> scheduling and billing.
>> ------------------------------
>>
>> *From:* Vladimir Prokofev [v at prokofev.me]
>> *Sent:* Wednesday, March 15, 2017 2:41 PM
>> *To:* OpenStack Operators
>> *Subject:* [Openstack-operators] Flavors
>>
>> A question of curiosity - why do we even need flavors?
>>
>>
>>
>> I do realise that we need a way to provide instance configuration, but
>> why use such a rigid construction? Wouldn't it be more flexible to provide
>> instance configuration as a set of parameters(metadata), and if you need
>> some presets - well, use a preconfigured set of them as a flavor in your
>> front-end(web/CLI client parameters)?
>>
>>
>>
>> Suppose commercial customer has an instance with high storage IO load.
>> Currently they have only one option - upsize instance to a flavor that
>> provides higher IOPS. But ususally provider has a limited amount of flavors
>> for purchase, and they upscale everything for a price. So instead of paying
>> only for IOPS customers are pushed to pay for whole package. This is good
>> from revenue point of view, but bad for customer's bank account and
>> marketing(i.e. product architecure limits).
>>
>> This applies to every resource - vCPU, RAM, storage, networking, etc -
>> everything is controlled by flavor.
>>
>>
>>
>> This concept has never been questioned anywhere I can search, so I have a
>> feeling I'm missing something big here. Maybe other ways are too
>> complicated to implement?
>>
>>
>>
>> So does anyone has any idea - why such rigid approach as flavors instead
>> of something more flexible?
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170315/3f00cacd/attachment.html>