Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170316/dc832db1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4764 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170316/dc832db1/attachment.bin>