<div dir="ltr">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.<div><br></div><div>Some comments about points raised already in this thread...</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Statement: breaks bin packing / have to match flavor dimensions to hardware dimensions.</div><div>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.</div><div><br></div><div>Other thoughts...</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div class="gmail_extra"><br><div class="gmail_quote">On 17 March 2017 at 04:21, Tomáš Vondra <span dir="ltr"><<a href="mailto:vondra@homeatcloud.cz" target="_blank">vondra@homeatcloud.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="CS"><div class="gmail-m_-2146887542403578698m_-7250067711294092468WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Tomas Vondra<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10pt;font-family:tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:tahoma,sans-serif"> Adam Lawson [mailto:<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.com</a>] <br><b>Sent:</b> Thursday, March 16, 2017 5:57 PM<br><b>To:</b> Jonathan D. Proulx<br><b>Cc:</b> OpenStack Operators<br><b>Subject:</b> Re: [Openstack-operators] Flavors<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">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.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">//adam<u></u><u></u></p></div></div><div><div class="gmail-m_-2146887542403578698h5"><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><div><div><div><div><div><div><p class="MsoNormal"><b><i><span style="font-family:arial,sans-serif"><br>Adam Lawson</span></i></b><span style="font-family:arial,sans-serif"><u></u><u></u></span></p></div><div><div><p class="MsoNormal"><span style="font-size:7.5pt;font-family:arial,sans-serif;color:rgb(102,102,102)"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:arial,sans-serif;color:rgb(102,102,102)">Principal Architect, CEO<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:arial,sans-serif;color:rgb(102,102,102)">Office: <a href="tel:(916)%20794-5706" value="+19167945706" target="_blank">+1-916-794-5706</a><u></u><u></u></span></p></div></div></div></div></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Mar 16, 2017 at 7:52 AM, Jonathan D. Proulx <<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>> wrote:<u></u><u></u></p><p class="MsoNormal"><br>I have always hated flavors and so do many of my users.<br><br>On Wed, Mar 15, 2017 at 03:22:48PM -0700, James Downs wrote:<br>:On Wed, Mar 15, 2017 at 10:10:00PM +0000, Fox, Kevin M wrote:<br>:> I think the really short answer is something like: It greatly simplifies scheduling and billing.<br>:<br>:The real answer is that once you buy hardware, it's in a fixed radio of CPU/Ram/Disk/IOPS, etc.<br><br>This while apparently reasonable is BS (at least in private cloud<br>space).  What users request and what they actualy use are wildly<br>divergent.<br><br>*IF* usage of claimed resorces were at or near optimal then this might<br>be true .  But if people are claiming 32G of ram because that how much<br>you assigned to a 16 vCPU instance type but really just need 16<br>threads with 2G or 4G then you packing still sucks.<br><br>I'm mostly bound on memory so I mostly have my users select on that<br>basis and over provide and over provision CPU since that can be<br>effectively shared between VMs where memory needs to be dedicated<br>(well mostly)<br><br>I'm sure I've ranted abotu this before but as you see from other<br>responses we seem to be in the minority position so mostly I rant at<br>the walls while my office mates look on perplexed (actually they're<br>pretty used to it by now and ignore me :) )<br><br>-Jon<u></u><u></u></p><div><div><p class="MsoNormal"><br>______________________________<wbr>_________________<br>OpenStack-operators mailing list<br><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><u></u><u></u></p></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div><br>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-2146887542403578698gmail_signature">Cheers,<br>~Blairo</div>
</div></div>