Open Stack

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 <jon at csail.mit.edu>
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 +0000, 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170316/fc1f3403/attachment.html>