Re: [Openstack-operators] Flavors
On 03/20/2017 04:24 PM, Blair Bethwaite wrote: For me an interesting question to know the answer to here would be at what point you have to stop resource sharing to guarantee your performance promises/SLAs (disregarding memory over-provisioning). My gut says that unless you are also doing all the other high-end performance tuning (CPU & memory pinning, NUMA topology, hugepages, optimised networking such as macvtap or SRIOV, plus all the regular host-side system/BIOS and power settings) you'll see very little benefit, i.e., under-provisioning on its own is not a performance win. Yes, that's a great question. Someone should do a paper on it. :) My suspicion would be that for a CPU-intensive workload you could probably gain quite a lot just by not overprovisioning your CPU. The host scheduler should end up balancing the busy virtual CPU threads across the available host CPUs. This will still result in periodic interruptions due to scheduler interruptions, RCU callbacks, etc. To get to the next level where the guest has near-hardware performance requires a bunch more work with host CPU isolation, IRQ affinity, RCU offload, etc. Once you get into a memory-bandwidth or network-bandwidth intensive workload then I agree you need to start caring about memory pinning, hugepages, NUMA topology, etc. Chris ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Flavors
Hi Chris, On 17 Mar. 2017 15:24, "Chris Friesen" wrote: On 03/16/2017 07:06 PM, Blair Bethwaite wrote: Statement: breaks bin packing / have to match flavor dimensions to hardware > dimensions. > Comment: neither of these ring true to me given that most operators tend to > agree that memory is there first constraining resource dimension and it is > difficult to achieve high CPU utilisation before memory is exhausted. Plus > virtualisation is inherently about resource sharing and over-provisioning, > Ah whoops, that was meant to be: "resource sharing and (optionally) over-provisioning", where I was broadly including security and convenience under resource sharing. There are of course many other factors. unless you have very detailed knowledge of your workloads a priori (or some > cycle-stealing/back-filling mechanism) you will always have > under-utilisation > (possibly quite high on average) in some resource dimensions. > I think this would be highly dependent on the workload. A virtual router is going to run out of CPU/network bandwidth far before memory is exhausted. Absolutely, which is why I hinted at today's general IaaS workload and said, "...unless you have very detailed knowledge of your workloads a priori". NFV focused clouds would clearly look quite different, and I suppose with the rise of OpenStack at telcos there would be quite a few such deployments floating around now. For similar reasons I'd disagree that virtualization is inherently about over-provisioning and suggest that (in some cases at least) it's more about flexibility over time. Our customers generally care about maximizing performance and so nothing is over-provisioned...disk, NICs, CPUs, RAM are generally all exclusively allocated. Sure, in our three Nova Cells we have a big mix of workload. One Cell is HPC oriented and so has no over-provisioning. Another is performance oriented (fast cores, fast network) but still moderately over-provisioned (cgroups to manage resource share between flavors). The other is general purpose. For me an interesting question to know the answer to here would be at what point you have to stop resource sharing to guarantee your performance promises/SLAs (disregarding memory over-provisioning). My gut says that unless you are also doing all the other high-end performance tuning (CPU & memory pinning, NUMA topology, hugepages, optimised networking such as macvtap or SRIOV, plus all the regular host-side system/BIOS and power settings) you'll see very little benefit, i.e., under-provisioning on its own is not a performance win. Cheers, Blair ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Flavors
On 03/16/2017 07:06 PM, Blair Bethwaite wrote: Statement: breaks bin packing / have to match flavor dimensions to hardware dimensions. Comment: neither of these ring true to me given that most operators tend to agree that memory is there first constraining resource dimension and it is difficult to achieve high CPU utilisation before memory is exhausted. Plus virtualisation is inherently about resource sharing and over-provisioning, unless you have very detailed knowledge of your workloads a priori (or some cycle-stealing/back-filling mechanism) you will always have under-utilisation (possibly quite high on average) in some resource dimensions. I think this would be highly dependent on the workload. A virtual router is going to run out of CPU/network bandwidth far before memory is exhausted. For similar reasons I'd disagree that virtualization is inherently about over-provisioning and suggest that (in some cases at least) it's more about flexibility over time. Our customers generally care about maximizing performance and so nothing is over-provisioned...disk, NICs, CPUs, RAM are generally all exclusively allocated. Chris ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Flavors
There have been previous proposals (and if memory serves, even some blueprints) for API extensions to allow this but they have apparently stagnated. On the face of it I think OpenStack should support this (more choice = win!) - doesn't mean that every cloud needs to use the feature. Is it worth trying to resurrect some feature development around this? Sounds like a potential forum session? We have already seen responses here from a number of active and prominent operators, some seem to be quite emotive, which could indicate this hits on some sore-points/bugbears. Some comments about points raised already in this thread... Statement: makes pricing hard because users can monopolise a subset of infrastructure resource dimensions (e.g. memory, disk IOPs) leading to some dimensions (e.g. CPU) being underutilised. Comment: it may exacerbate the problem if users can request resource dimensions with no limits or dependencies imposed, but that problem typically already exists to some extent in any general-purpose deployment - as others have mentioned they mostly find themselves constrained by memory. That does not seem like a hard problem to workaround, e.g., dimensions could have both absolute lower and upper bounds plus dynamic bounds based on the setting of other dimensions. Statement: breaks bin packing / have to match flavor dimensions to hardware dimensions. Comment: neither of these ring true to me given that most operators tend to agree that memory is there first constraining resource dimension and it is difficult to achieve high CPU utilisation before memory is exhausted. Plus virtualisation is inherently about resource sharing and over-provisioning, unless you have very detailed knowledge of your workloads a priori (or some cycle-stealing/back-filling mechanism) you will always have under-utilisation (possibly quite high on average) in some resource dimensions. Other thoughts... A feature such as this also opens up the interesting possibility of soft/fuzzy resource requests, which could be very useful in a private (i.e. constrained) cloud environment, e.g., "give me an instance with 2-4 cores and 8-16GB RAM and at least 500 IOPs". Some of the statements in this thread also lend credence to the need for a way to provide preemptible instances which would provide one way to back-fill compute/cpu based resources. Cheers, On 17 March 2017 at 04:21, Tomáš Vondra wrote: > We at Homeatcloud.com do exactly this in our VPS service. The user can > configure the VPS with any combination of CPU, RAM, and disk. However a) > the configurations are all about 10% the size of the physical machines and > b) the disks are in a SAN array, provisioned as volumes. So I give the > users some flexibility and can better see what configurations they actually > want and build new hypervisors with that in mind. They mostly want up to 4 > GB RAM anyway, si it’s not a big deal. > > Tomas Vondra > > > > *From:* Adam Lawson [mailto:alaw...@aqorn.com] > *Sent:* Thursday, March 16, 2017 5:57 PM > *To:* Jonathan D. Proulx > *Cc:* OpenStack Operators > *Subject:* Re: [Openstack-operators] Flavors > > > > One way I know some providers work around this when using OpenStack is by > fronting the VM request with some code in the web server that checks if the > requested spec has an existing flavor. if so, use the flavor, if not, use > an admin account that creates a new flavor and assign use it for that user > request then remove if when the build is complete. This naturally impacts > your control over hardware efficiency but it makes your scenario possible > (for better or for worse). I also hate being forced to do what someone else > decided was going to be best for me. That's my decision and thanksully with > openStack, this kind of thing is rather easy to do. > > > > //adam > > > > *Adam Lawson* > > > > Principal Architect, CEO > > Office: +1-916-794-5706 <(916)%20794-5706> > > > > On Thu, Mar 16, 2017 at 7:52 AM, Jonathan D. Proulx > wrote: > > > I have always hated flavors and so do many of my users. > > On Wed, Mar 15, 2017 at 03:22:48PM -0700, James Downs wrote: > :On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote: > :> I think the really short answer is something like: It greatly > simplifies scheduling and billing. > : > :The real answer is that once you buy hardware, it's in a fixed radio of > CPU/Ram/Disk/IOPS, etc. > > This while apparently reasonable is BS (at least in private cloud > space). What users request and what they actualy use are wildly > divergent. > > *IF* usage of claimed resorces were at or near optimal then this might > be true . But if people are claiming 32G of ram because that how much > you assigned to a 16 vCPU instance type but really just need 16 > thr
Re: [Openstack-operators] Flavors
We at Homeatcloud.com do exactly this in our VPS service. The user can configure the VPS with any combination of CPU, RAM, and disk. However a) the configurations are all about 10% the size of the physical machines and b) the disks are in a SAN array, provisioned as volumes. So I give the users some flexibility and can better see what configurations they actually want and build new hypervisors with that in mind. They mostly want up to 4 GB RAM anyway, si it’s not a big deal. Tomas Vondra From: Adam Lawson [mailto:alaw...@aqorn.com] Sent: Thursday, March 16, 2017 5:57 PM To: Jonathan D. Proulx Cc: OpenStack Operators Subject: Re: [Openstack-operators] Flavors One way I know some providers work around this when using OpenStack is by fronting the VM request with some code in the web server that checks if the requested spec has an existing flavor. if so, use the flavor, if not, use an admin account that creates a new flavor and assign use it for that user request then remove if when the build is complete. This naturally impacts your control over hardware efficiency but it makes your scenario possible (for better or for worse). I also hate being forced to do what someone else decided was going to be best for me. That's my decision and thanksully with openStack, this kind of thing is rather easy to do. //adam Adam Lawson Principal Architect, CEO Office: +1-916-794-5706 On Thu, Mar 16, 2017 at 7:52 AM, Jonathan D. Proulx wrote: I have always hated flavors and so do many of my users. On Wed, Mar 15, 2017 at 03:22:48PM -0700, James Downs wrote: :On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote: :> I think the really short answer is something like: It greatly simplifies scheduling and billing. : :The real answer is that once you buy hardware, it's in a fixed radio of CPU/Ram/Disk/IOPS, etc. This while apparently reasonable is BS (at least in private cloud space). What users request and what they actualy use are wildly divergent. *IF* usage of claimed resorces were at or near optimal then this might be true . But if people are claiming 32G of ram because that how much you assigned to a 16 vCPU instance type but really just need 16 threads with 2G or 4G then you packing still sucks. I'm mostly bound on memory so I mostly have my users select on that basis and over provide and over provision CPU since that can be effectively shared between VMs where memory needs to be dedicated (well mostly) I'm sure I've ranted abotu this before but as you see from other responses we seem to be in the minority position so mostly I rant at the walls while my office mates look on perplexed (actually they're pretty used to it by now and ignore me :) ) -Jon ___ 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
Re: [Openstack-operators] Flavors
One way I know some providers work around this when using OpenStack is by fronting the VM request with some code in the web server that checks if the requested spec has an existing flavor. if so, use the flavor, if not, use an admin account that creates a new flavor and assign use it for that user request then remove if when the build is complete. This naturally impacts your control over hardware efficiency but it makes your scenario possible (for better or for worse). I also hate being forced to do what someone else decided was going to be best for me. That's my decision and thanksully with openStack, this kind of thing is rather easy to do. //adam *Adam Lawson* Principal Architect, CEO Office: +1-916-794-5706 On Thu, Mar 16, 2017 at 7:52 AM, Jonathan D. Proulx wrote: > > I have always hated flavors and so do many of my users. > > On Wed, Mar 15, 2017 at 03:22:48PM -0700, James Downs wrote: > :On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote: > :> I think the really short answer is something like: It greatly > simplifies scheduling and billing. > : > :The real answer is that once you buy hardware, it's in a fixed radio of > CPU/Ram/Disk/IOPS, etc. > > This while apparently reasonable is BS (at least in private cloud > space). What users request and what they actualy use are wildly > divergent. > > *IF* usage of claimed resorces were at or near optimal then this might > be true . But if people are claiming 32G of ram because that how much > you assigned to a 16 vCPU instance type but really just need 16 > threads with 2G or 4G then you packing still sucks. > > I'm mostly bound on memory so I mostly have my users select on that > basis and over provide and over provision CPU since that can be > effectively shared between VMs where memory needs to be dedicated > (well mostly) > > I'm sure I've ranted abotu this before but as you see from other > responses we seem to be in the minority position so mostly I rant at > the walls while my office mates look on perplexed (actually they're > pretty used to it by now and ignore me :) ) > > -Jon > > ___ > 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
Re: [Openstack-operators] Flavors
I have always hated flavors and so do many of my users. On Wed, Mar 15, 2017 at 03:22:48PM -0700, James Downs wrote: :On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote: :> I think the really short answer is something like: It greatly simplifies scheduling and billing. : :The real answer is that once you buy hardware, it's in a fixed radio of CPU/Ram/Disk/IOPS, etc. This while apparently reasonable is BS (at least in private cloud space). What users request and what they actualy use are wildly divergent. *IF* usage of claimed resorces were at or near optimal then this might be true . But if people are claiming 32G of ram because that how much you assigned to a 16 vCPU instance type but really just need 16 threads with 2G or 4G then you packing still sucks. I'm mostly bound on memory so I mostly have my users select on that basis and over provide and over provision CPU since that can be effectively shared between VMs where memory needs to be dedicated (well mostly) I'm sure I've ranted abotu this before but as you see from other responses we seem to be in the minority position so mostly I rant at the walls while my office mates look on perplexed (actually they're pretty used to it by now and ignore me :) ) -Jon ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Flavors
Follow-up thought: > 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? This topic does get brought up from time to time, but in different areas under different names. Off of the top of my head, a past discussion about quota management and how one could limit the amount of SSD disk space a user could use while giving them larger access to a spindle disk. Being able to manage different characteristics about a resource (disk size vs disk IOPS) is a complicated thing to do and it's certainly not a solved problem. I don't want to say something like "flavors are just the accepted norm" because that would be doing them a huge injustice, but I did want to follow-up and say that you're not alone if you've hit issues with the way resources are bundled. :) On Wed, Mar 15, 2017 at 10:31 PM, Joe Topjian wrote: > 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 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 >> 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 >> *Date: *Wednesday, March 15, 2017 at 5:42 PM >> *To: *"Fox, Kevin M" >> *Cc: *OpenStack Operators >> *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 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 mi
Re: [Openstack-operators] Flavors
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 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 > 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 > *Date: *Wednesday, March 15, 2017 at 5:42 PM > *To: *"Fox, Kevin M" > *Cc: *OpenStack Operators > *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 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
Re: [Openstack-operators] Flavors
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 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 > Date: Wednesday, March 15, 2017 at 5:42 PM > To: "Fox, Kevin M" > Cc: OpenStack Operators > 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 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
Re: [Openstack-operators] Flavors
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 Date: Wednesday, March 15, 2017 at 5:42 PM To: "Fox, Kevin M" Cc: OpenStack Operators 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 mailto: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<mailto: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<mailto: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
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 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
Re: [Openstack-operators] Flavors
I think it can help add enough predictability and structure to keep costs down as well. If you know the end users will be using 1 of 25 different pre-configured packages, you can somewhat reliably configure hardware sku's around that because often the packages are a fractional size of the hardware platform. If you open it up to anything goes, you run the risk of having someone that wants 2 cores and 200GB of memory for some SQL server. They want everything in memory but they don't want to pay the M$ licenses for additional cores. So now you have a vm on a physical server somewhere with excess CPU cycles that can't be used because the VM that's on it has sucked up all the memory. The poor utilization of resources then result in increase overhead and higher costs due to the inefficiencies. From: Fox, Kevin M Sent: Wednesday, March 15, 2017 5:10 PM To: Vladimir Prokofev; OpenStack Operators Subject: Re: [Openstack-operators] Flavors 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
Re: [Openstack-operators] Flavors
On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote: > I think the really short answer is something like: It greatly simplifies > scheduling and billing. The real answer is that once you buy hardware, it's in a fixed radio of CPU/Ram/Disk/IOPS, etc. In order to use the hardware effectively, you need to make a set of flavors that fit into the hardware appropriately. If some customer comes along and takes all the ram, or cpu, for example, effectively, no one else can use the rest of the machine. That's why the public cloud vendors have different physical SKUs for the different classes of flavors, and you'll find different ratios of resources across them. Cheers, -j ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Flavors
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] 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
