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 <joml...@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 <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 > > > _______________________________________________ > 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
