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....@pnnl.gov> wrote: > I think the really short answer is something like: It greatly simplifies > scheduling and billing. > > ------------------------------ > *From:* Vladimir Prokofev [v...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
