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 <klindg...@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 <mkfmn...@gmail.com> > Date: Wednesday, March 15, 2017 at 5:42 PM > To: "Fox, Kevin M" <kevin....@pnnl.gov> > Cc: OpenStack Operators <openstack-operators@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....@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
