Open Stack

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/7baba585/attachment.html>