Adding the dev list. I would to see also the devs opinion in this blueprint, we need to discuss the approach for this.
https://review.openstack.org/#/c/84432/9 -----Original Message----- From: Cazzolato, Sergio J Sent: Wednesday, April 16, 2014 5:47 PM To: Cazzolato, Sergio J; James Penick; Tim Bell; Narayan Desai; Jay Pipes Cc: [email protected] Subject: RE: [Openstack-operators] Quota Templates I would to see the operators opinion in this blueprint, we need to understand if it is useful or it is confusing for you. https://review.openstack.org/#/c/84432/9 -----Original Message----- From: Cazzolato, Sergio J [mailto:[email protected]] Sent: Friday, April 11, 2014 12:38 PM To: James Penick; Tim Bell; Narayan Desai; Jay Pipes Cc: [email protected] Subject: Re: [Openstack-operators] Quota Templates Thanks James! I think we will need some help for code review and to test this in a real cluster. -----Original Message----- From: James Penick [mailto:[email protected]] Sent: Thursday, April 10, 2014 2:44 PM To: Cazzolato, Sergio J; Tim Bell; Narayan Desai; Jay Pipes Cc: [email protected] Subject: Re: [Openstack-operators] Quota Templates This certainly covers our immediate needs. Longer term we should consider how to cascade this concept through cells, and allow someone to have a quota for a given flavor in a given cell type. For example, I may allow them 100 m1.medium flavors in a 0 over provisioning cell, but 500 in a highly over provisioned cell. Something to consider. That said, there are some dev resources that we have available to us. Want some help getting this in? -James :)= On 4/9/14, 2:17 PM, "Cazzolato, Sergio J" <[email protected]> wrote: >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:[email protected]] >Sent: Wednesday, April 09, 2014 5:16 PM >To: Cazzolato, Sergio J; James Penick; Narayan Desai; Jay Pipes >Cc: [email protected] >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:[email protected]] >Sent: 09 April 2014 21:28 >To: James Penick; Tim Bell; Narayan Desai; Jay Pipes >Cc: [email protected] >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:[email protected]] >Sent: Tuesday, April 08, 2014 6:37 PM >To: Tim Bell; Narayan Desai; Jay Pipes >Cc: [email protected] >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 <[email protected]> >Date: Monday, April 7, 2014 at 11:45 AM >To: Narayan Desai <[email protected]>, Jay Pipes ><[email protected]> >Cc: "[email protected]" ><[email protected]> >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:[email protected]] >Sent: 07 April 2014 20:33 >To: Jay Pipes >Cc: [email protected] >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 _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
