Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170315/499e519c/attachment.html>