Open Stack

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 <vondra at homeatcloud.cz> 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:alawson at 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 <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
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170317/ffb42364/attachment.html>