Open Stack

Yes, this would seem to cover it.

Tim

> -----Original Message-----
> From: Cazzolato, Sergio J [mailto:sergio.j.cazzolato at intel.com]
> Sent: 09 April 2014 23:17
> To: Tim Bell; James Penick; Narayan Desai; Jay Pipes
> Cc: openstack-operators at lists.openstack.org
> Subject: RE: [Openstack-operators] Quota Templates
> 
> So far the plan is to make it by project/user. The idea for the flavor quotas is that could be used combined with other resources or
> alone.
> 
> Example:
> Suppose this scenario:
> . flavor medium has 2 cores and 4GB ram
> . flavor large has 4 cores and 8GB ram
> 
> Today we can assign in this way the quotas per user:
> . Instances: 4
> . Cores: 8
> . Ram: 16GB
> 
> Through this feature:
> . flavor medium: 4
> Or
> . flavor large: 2
> Or
> . flavor medium: 2
> . flavor large: 1
> Or
> .flavor medium: 4
> . Instances: 4
> . Cores: 8
> . Ram: 16GB
> 
> So,
> In case the quotas for a user is flavor_medium: 4 The idea is that when the user creates a machine and it is based on a flavor
> medium, if the user has already created 4 machines the system will not allow this, otherwise it will allow it. And in case the user
> wants to create a large one, the system will deny that.
> 
> Does it make sense?
> 
> Do you think it is enough to cover the scenarios for specific hardware as you mention in previous emails?
> 
> From: Tim Bell [mailto:Tim.Bell at cern.ch]
> Sent: Wednesday, April 09, 2014 5:16 PM
> To: Cazzolato, Sergio J; James Penick; Narayan Desai; Jay Pipes
> Cc: openstack-operators at lists.openstack.org
> Subject: RE: [Openstack-operators] Quota Templates
> 
> 
> Addressing all of CERN’s needs would be a big patch ☺
> 
> I can see a few scenarios which may be overlapping
> 
> The quota for a project should be (optionally) set such that the number of a particular flavour is limited. Examples would be very
> large VMs or flavors which match specific aggregates on a different allocation scheme.
> 
> Can you clarify the scope of the quota ? Are we setting it per user, per group (with Keystone V3 this is supported) and/or per project ?
> 
> Tim
> 
> From: Cazzolato, Sergio J [mailto:sergio.j.cazzolato at intel.com]
> Sent: 09 April 2014 21:28
> To: James Penick; Tim Bell; Narayan Desai; Jay Pipes
> Cc: openstack-operators at lists.openstack.org
> Subject: RE: [Openstack-operators] Quota Templates
> 
> Hi James, thanks for sharing with us.
> 
> I am working in the blueprint “per-flavor-quotas” and I would to know based on your datacenter needs, if this feature is covering all
> the problems you have regarding this topic? Or we should complement that with something else?
> 
> https://review.openstack.org/#/c/84432/7
> 
> Thanks
> 
> 
> From: James Penick [mailto:penick at yahoo-inc.com]
> Sent: Tuesday, April 08, 2014 6:37 PM
> To: Tim Bell; Narayan Desai; Jay Pipes
> Cc: openstack-operators at lists.openstack.org
> Subject: Re: [Openstack-operators] Quota Templates
> 
> This all seems to be going in a great direction.
> 
>  One of the things I’ve been working on at Yahoo is integrating Openstack VMs and Bare metal into our larger finance process. We
> have a couple interesting problems presented by the current quota management system.
> 
>  When one of our Projects on our internal cloud wants to increase their quota they’ll need to file a request. That request will be
> compared against projected cluster capacity as well as certain financial models. If the request falls within certain parameters it’ll need
> larger finance approval before the quota can be allocated.  There are a number of capacity folks who would be handling these
> requests, so there could be a race condition when multiple Projects request capacity at the same time. So not only do we need a way
> to grant and track quota increases, but also to have a concept of state management within a given quota request. The advantage of
> state management is an enterprise can track why and when a given quota increase was requested and granted. Especially if there’s a
> field to track an external reference ID (like a bug/ticket number).  The big change is that we will no longer have one item in the DB
> per-Project-per-resource, but instead it’d be per-Project-per-resource-per-request. This means we’d also need to extend nova to
> support the concept of ‘Soft’ and ‘hard’ quota. Hard quota being what you can actually allocate against, and ‘soft’ quota would let
> you see what you have + what’s in the pipe for approval.
> 
>  Now for flavor-level quotas. We, too have a use case where we need to limit a Project to certain ‘flavor’ types. In our case it’s
> primarily our bare metal deployment, but I might want to grant a Project differing levels of quota within different cluster types. For
> example, I might want to have some hypervisors slated for no over provisioning, while others would be available at an extremely high
> over provision rate. This would let me guide our internal tenants onto the best possible resources with the right SLA and price point.
> As was mentioned earlier in the thread there would also be value in granting quota against a certain hardware type. SSD hypervisors,
> hypervisors with SSL accelerators, etc etc.  There are a lot of ways I can see slicing the pie in my data centers.
> 
> While both of these things are of definite need to the enterprise running private clouds, I imagine the smaller public cloud provider
> would need them just as much.
> 
> Tim, would you (or anyone else) care to work together on the blueprint and reboot Boson? I can contribute insight and code..
> 
> Thanks!
> -James
> 
> :)=
> 
> 
> From: Tim Bell <Tim.Bell at cern.ch>
> Date: Monday, April 7, 2014 at 11:45 AM
> To: Narayan Desai <narayan.desai at gmail.com>, Jay Pipes <jaypipes at gmail.com>
> Cc: "openstack-operators at lists.openstack.org" <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Quota Templates
> 
> 
> We can add some more CERN brass for this scenario. We want to fill up workload spread across the maximum number of hypervisors
> (don’t overcommit unless you have to) but that means as you approach full, you can only give out small VMs that fit in the cracks.
> 
> In my ideal world, we would have a way of saying schedule for maximum distribution across hypervisors but make sure that there are
> X slots free for flavour A, Y slots free for flavour B etc for requests that exactly match that resource.
> 
> Given a 3-4 year purchasing cycle, the Thailand floods means HDDs were not available in volume and varying processor prices, we’ve
> got a large mixture of different configurations.
> 
> It’s a really tough problem to do this at scale and quickly but I’d love to discuss/debate the options available to be able to turn the
> cloud efficiency up to 11 ☺
> 
> Tim
> 
> From: Narayan Desai [mailto:narayan.desai at gmail.com]
> Sent: 07 April 2014 20:33
> To: Jay Pipes
> Cc: openstack-operators at lists.openstack.org
> Subject: Re: [Openstack-operators] Quota Templates
> 
> …
> 
> You must be using a much smarter openstack scheduler than I am. I'll agree in principle that this could be true, however,
> fragmentation avoidance is tricky problem, particularly when you have a big range of potential configuration. YOu can only imagine
> the sad trombone that played in my office the first time the scheduler placed an 8GB instance on a bigmem node, blocking that
> system's largest configuration from being usable. We've personally had a lot more luck partitioning resources, and picking a set of
> favorable resource combinations than letting the scheduler deal with it.
> 
> This is a great discussion. I think that we need more of this kind of thing on the operators list.
>  -nld