Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
Hi, Basically we should kill quota classes. It required out of tree stuff that was never implemented, AFAIK. When I checked with Kevin about this, my memory says the idea was out of tree authorization plugin would populate context.quota_class with something like "i_have_big_credit_limit" or "i_have_prepaid_loads_limit", and if blank fall back to the default. I don't believe anyone ever used that system. Gives you like groups of pre-defined quota limits, rather than per project overrides. Either way, it should die, and now its keystone's problem. I subscribe to the idea that downstream operational scripting is the currently preferred solution. Thanks, johnthetubaguy PS Sorry been busy on SKA architecture last month or so, slowing getting back up to speed. On Fri, 26 Oct 2018 at 14:55, Jay Pipes wrote: > > On 10/25/2018 02:44 PM, melanie witt wrote: > > On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote: > >> On 10/25/2018 01:38 PM, Chris Friesen wrote: > >>> On 10/24/2018 9:10 AM, Jay Pipes wrote: > Nova's API has the ability to create "quota classes", which are > basically limits for a set of resource types. There is something > called the "default quota class" which corresponds to the limits in > the CONF.quota section. Quota classes are basically templates of > limits to be applied if the calling project doesn't have any stored > project-specific limits. > > Has anyone ever created a quota class that is different from "default"? > >>> > >>> The Compute API specifically says: > >>> > >>> "Only ‘default’ quota class is valid and used to set the default quotas, > >>> all other quota class would not be used anywhere." > >>> > >>> What this API does provide is the ability to set new default quotas for > >>> *all* projects at once rather than individually specifying new defaults > >>> for each project. > >> > >> It's a "defaults template", yes. > >> > >> The alternative is, you know, to just set the default values in > >> CONF.quota, which is what I said above. Or, if you want project X to > >> have different quota limits from those CONF-driven defaults, then set > >> the quotas for the project to some different values via the > >> os-quota-sets API (or better yet, just use Keystone's /limits API when > >> we write the "limits driver" into Nova). The issue is that the > >> os-quota-classes API is currently blocking *me* writing that "limits > >> driver" in Nova because I don't want to port nova-specific functionality > >> (like quota classes) to a limits driver when the Keystone /limits > >> endpoint doesn't have that functionality and nobody I know of has ever > >> used it. > > > > When you say it's blocking you from writing the "limits driver" in nova, > > are you saying you're picking up John's unified limits spec [1]? It's > > been in -W mode and hasn't been updated in 4 weeks. In the spec, > > migration from quota classes => registered limits and deprecation of the > > existing quota API and quota classes is described. > > > > Cheers, > > -melanie > > > > [1] https://review.openstack.org/602201 > > Actually, I wasn't familiar with John's spec. I'll review it today. > > I was referring to my own attempts to clean up the quota system and > remove all the limits-related methods from the QuotaDriver class... > > Best, > -jay > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/25/2018 02:44 PM, melanie witt wrote: On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the calling project doesn't have any stored project-specific limits. Has anyone ever created a quota class that is different from "default"? The Compute API specifically says: "Only ‘default’ quota class is valid and used to set the default quotas, all other quota class would not be used anywhere." What this API does provide is the ability to set new default quotas for *all* projects at once rather than individually specifying new defaults for each project. It's a "defaults template", yes. The alternative is, you know, to just set the default values in CONF.quota, which is what I said above. Or, if you want project X to have different quota limits from those CONF-driven defaults, then set the quotas for the project to some different values via the os-quota-sets API (or better yet, just use Keystone's /limits API when we write the "limits driver" into Nova). The issue is that the os-quota-classes API is currently blocking *me* writing that "limits driver" in Nova because I don't want to port nova-specific functionality (like quota classes) to a limits driver when the Keystone /limits endpoint doesn't have that functionality and nobody I know of has ever used it. When you say it's blocking you from writing the "limits driver" in nova, are you saying you're picking up John's unified limits spec [1]? It's been in -W mode and hasn't been updated in 4 weeks. In the spec, migration from quota classes => registered limits and deprecation of the existing quota API and quota classes is described. Cheers, -melanie [1] https://review.openstack.org/602201 Actually, I wasn't familiar with John's spec. I'll review it today. I was referring to my own attempts to clean up the quota system and remove all the limits-related methods from the QuotaDriver class... Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On Thu, 25 Oct 2018 15:06:38 -0500, Matt Riedemann wrote: On 10/25/2018 2:55 PM, Chris Friesen wrote: 2) The main benefit (as I see it) of the quota class API is to allow dynamic adjustment of the default quotas without restarting services. I could be making this up, but I want to say back at the Pike PTG people were also complaining that not having an API to change this, and only do it via config, was not good. But if the keystone limits API solves that then it's a non-issue. Right, the default limits are "registered limits" [1] in the keystone API. And "project limits" can be set to override "registered limits". So the keystone limits API does solve that case. -melanie [1] https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html#registered-limits __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/25/2018 2:55 PM, Chris Friesen wrote: 2) The main benefit (as I see it) of the quota class API is to allow dynamic adjustment of the default quotas without restarting services. I could be making this up, but I want to say back at the Pike PTG people were also complaining that not having an API to change this, and only do it via config, was not good. But if the keystone limits API solves that then it's a non-issue. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/25/2018 12:00 PM, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the calling project doesn't have any stored project-specific limits. Has anyone ever created a quota class that is different from "default"? The Compute API specifically says: "Only ‘default’ quota class is valid and used to set the default quotas, all other quota class would not be used anywhere." What this API does provide is the ability to set new default quotas for *all* projects at once rather than individually specifying new defaults for each project. It's a "defaults template", yes. Chris, are you advocating for *keeping* the os-quota-classes API? Nope. I had two points: 1) It's kind of irrelevant whether anyone has created a quota class other than "default" because nova wouldn't use it anyways. 2) The main benefit (as I see it) of the quota class API is to allow dynamic adjustment of the default quotas without restarting services. I totally agree that keystone limits should replace it. I just didn't want the discussion to be focused on the non-default class portion because it doesn't matter. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the calling project doesn't have any stored project-specific limits. Has anyone ever created a quota class that is different from "default"? The Compute API specifically says: "Only ‘default’ quota class is valid and used to set the default quotas, all other quota class would not be used anywhere." What this API does provide is the ability to set new default quotas for *all* projects at once rather than individually specifying new defaults for each project. It's a "defaults template", yes. The alternative is, you know, to just set the default values in CONF.quota, which is what I said above. Or, if you want project X to have different quota limits from those CONF-driven defaults, then set the quotas for the project to some different values via the os-quota-sets API (or better yet, just use Keystone's /limits API when we write the "limits driver" into Nova). The issue is that the os-quota-classes API is currently blocking *me* writing that "limits driver" in Nova because I don't want to port nova-specific functionality (like quota classes) to a limits driver when the Keystone /limits endpoint doesn't have that functionality and nobody I know of has ever used it. When you say it's blocking you from writing the "limits driver" in nova, are you saying you're picking up John's unified limits spec [1]? It's been in -W mode and hasn't been updated in 4 weeks. In the spec, migration from quota classes => registered limits and deprecation of the existing quota API and quota classes is described. Cheers, -melanie [1] https://review.openstack.org/602201 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the calling project doesn't have any stored project-specific limits. Has anyone ever created a quota class that is different from "default"? The Compute API specifically says: "Only ‘default’ quota class is valid and used to set the default quotas, all other quota class would not be used anywhere." What this API does provide is the ability to set new default quotas for *all* projects at once rather than individually specifying new defaults for each project. It's a "defaults template", yes. The alternative is, you know, to just set the default values in CONF.quota, which is what I said above. Or, if you want project X to have different quota limits from those CONF-driven defaults, then set the quotas for the project to some different values via the os-quota-sets API (or better yet, just use Keystone's /limits API when we write the "limits driver" into Nova). The issue is that the os-quota-classes API is currently blocking *me* writing that "limits driver" in Nova because I don't want to port nova-specific functionality (like quota classes) to a limits driver when the Keystone /limits endpoint doesn't have that functionality and nobody I know of has ever used it. Chris, are you advocating for *keeping* the os-quota-classes API? Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the calling project doesn't have any stored project-specific limits. Has anyone ever created a quota class that is different from "default"? The Compute API specifically says: "Only ‘default’ quota class is valid and used to set the default quotas, all other quota class would not be used anywhere." What this API does provide is the ability to set new default quotas for *all* projects at once rather than individually specifying new defaults for each project. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
melanie witt wrote on 10/25/2018 02:14:40 AM: > On Thu, 25 Oct 2018 14:12:51 +0900, ボーアディネシュ[bhor Dinesh] wrote: > > We were having a similar use case like *Preemptible Instances* called as > > *Rich-VM’s* which > > > > are high in resources and are deployed each per hypervisor. We have a > > custom code in > > > > production which tracks the quota for such instances separately and for > > the same reason > > > > we have *rich_instances* custom quota class same as *instances* quota class. > > Please see the last reply I recently sent on this thread. I have been > thinking the same as you about how we could use quota classes to > implement the quota piece of preemptible instances. I think we can > achieve the same thing using unified limits, specifically registered > limits [1], which span across all projects. So, I think we are covered > moving forward with migrating to unified limits and deprecation of quota > classes. Let me know if you spot any issues with this idea. And we could finally close https://bugs.launchpad.net/nova/+bug/1602396 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On Thu, 25 Oct 2018 14:12:51 +0900, ボーアディネシュ[bhor Dinesh] wrote: We were having a similar use case like *Preemptible Instances* called as *Rich-VM’s* which are high in resources and are deployed each per hypervisor. We have a custom code in production which tracks the quota for such instances separately and for the same reason we have *rich_instances* custom quota class same as *instances* quota class. Please see the last reply I recently sent on this thread. I have been thinking the same as you about how we could use quota classes to implement the quota piece of preemptible instances. I think we can achieve the same thing using unified limits, specifically registered limits [1], which span across all projects. So, I think we are covered moving forward with migrating to unified limits and deprecation of quota classes. Let me know if you spot any issues with this idea. Cheers, -melanie [1] https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On Wed, 24 Oct 2018 12:54:00 -0700, Melanie Witt wrote: On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem to find anyone who has ever used it. Deprecating this API and functionality would make the transition to a saner quota management system much easier and straightforward. I was trying to do this before it was cool: https://review.openstack.org/#/c/411035/ I think it was the Pike PTG in ATL where people said, "meh, let's just wait for unified limits from keystone and let this rot on the vine". I'd be happy to restore and update that spec. Yeah, we were thinking the presence of the API and code isn't harming anything and sometimes we talk about situations where we could use them. Quota classes come up occasionally whenever we talk about preemptible instances. Example: we could create and use a quota class "preemptible" and decorate preemptible flavors with that quota_class in order to give them unlimited quota. There's also talk of quota classes in the "Count quota based on resource class" spec [1] where we could have leveraged quota classes to create and enforce quota limits per custom resource class. But I think the consensus there was to hold off on quota by custom resource class until we migrate to unified limits and oslo.limit. So, I think my concern in removing the internal code that is capable of enforcing quota limit per quota class is the preemptible instance use case. I don't have my mind wrapped around if/how we could solve it using unified limits yet. And I was just thinking, if we added a project_id column to the quota_classes table and correspondingly added it to the os-quota-class-sets API, we could pretty simply implement quota by flavor, which is a feature operators like Oath need. An operator could create a quota class limit per project_id and then decorate flavors with quota_class to enforce them per flavor. I recognize that maybe it would be too confusing to solve use cases with quota classes given that we're going to migrate to united limits. At the same time, I'm hesitant to close the door on a possibility before we have some idea about how we'll solve them without quota classes. Has anyone thought about how we can solve the use cases with unified limits for things like preemptible instances and quota by flavor? [1] https://review.openstack.org/56901 After I sent this, I realized that I _have_ thought about how to solve these use cases with unified limits before and commented about it on the "Count quota based on resource class" spec some months ago. For preemptible instances, we could leverage registered limits in keystone [2] (registered limits span across all projects) by creating a limit with resource_name='preemptible', for example. Then we could decorate a flavor with quota_resource_name='preemptible' which would designate a preemptible instance type. Then we use the quota_resource_name from the flavor to check the quota for the corresponding registered limit in keystone. This way, preemptible instances can be assigned their own special quota (probably unlimited). And for quota by flavor, same concept. I think we could use registered limits and project limits [3] by creating limits with resource_name='flavorX', for example. We could decorate flavors with quota_resource_name='flavorX' and check quota for special quota for flavorX. Unified limits provide all of the same ability as quota classes, as far as I can tell. Given that, I think we are OK to deprecate quota classes. Cheers, -melanie [2] https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits [3] https://developer.openstack.org/api-ref/identit/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-limits __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
Hi All, We were having a similar use case like *Preemptible Instances* called as *Rich-VM’s* which are high in resources and are deployed each per hypervisor. We have a custom code in production which tracks the quota for such instances separately and for the same reason we have *rich_instances* custom quota class same as *instances* quota class. I discussed this thing pretty recently with sean-k-mooney I hope he remembers it. ボーアディネシュ Bhor Dinesh Verda2チーム 〒160-0022 東京都新宿区新宿4-1-6 JR新宿ミライナタワー 23階 Mobile 08041289520 Fax 03-4316-2116 Email dinesh.b...@linecorp.com -Original Message- From: "Kevin L. Mitchell" To: "OpenStack Development Mailing List (not for usage questions)"; "openstack-operat...@lists.openstack.org"; Cc: Sent: Oct 25, 2018 (Thu) 11:35:08 Subject: Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova? > On 10/24/18 10:10, Jay Pipes wrote: > > Nova's API has the ability to create "quota classes", which are > > basically limits for a set of resource types. There is something called > > the "default quota class" which corresponds to the limits in the > > CONF.quota section. Quota classes are basically templates of limits to > > be applied if the calling project doesn't have any stored > > project-specific limits. For the record, my original concept in creating quota classes is that you'd be able to set quotas per tier of user and easily be able to move users from one tier to another. This was just a neat idea I had, and AFAIK, Rackspace never used it, so you can call it YAGNI as far as I'm concerned :) > > Has anyone ever created a quota class that is different from "default"? > > > > I'd like to propose deprecating this API and getting rid of this > > functionality since it conflicts with the new Keystone /limits endpoint, > > is highly coupled with RAX's turnstile middleware I didn't intend it to be highly coupled, but it's been a while since I wrote it, and of course I've matured as a developer since then, so *shrug*. I also don't think Rackspace has ever used turnstile. > > and I can't seem to > > find anyone who has ever used it. Deprecating this API and functionality > > would make the transition to a saner quota management system much easier > > and straightforward. I'm fine with that plan, speaking as the original developer; as I say, I don't think Rackspace ever utilized the functionality anyway, and if no one else pipes up saying that they're using it, I'd be all over deprecating the quota classes in favor of the new hotness. -- Kevin L. Mitchell __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
> On 10/24/18 10:10, Jay Pipes wrote: > > Nova's API has the ability to create "quota classes", which are > > basically limits for a set of resource types. There is something called > > the "default quota class" which corresponds to the limits in the > > CONF.quota section. Quota classes are basically templates of limits to > > be applied if the calling project doesn't have any stored > > project-specific limits. For the record, my original concept in creating quota classes is that you'd be able to set quotas per tier of user and easily be able to move users from one tier to another. This was just a neat idea I had, and AFAIK, Rackspace never used it, so you can call it YAGNI as far as I'm concerned :) > > Has anyone ever created a quota class that is different from "default"? > > > > I'd like to propose deprecating this API and getting rid of this > > functionality since it conflicts with the new Keystone /limits endpoint, > > is highly coupled with RAX's turnstile middleware I didn't intend it to be highly coupled, but it's been a while since I wrote it, and of course I've matured as a developer since then, so *shrug*. I also don't think Rackspace has ever used turnstile. > > and I can't seem to > > find anyone who has ever used it. Deprecating this API and functionality > > would make the transition to a saner quota management system much easier > > and straightforward. I'm fine with that plan, speaking as the original developer; as I say, I don't think Rackspace ever utilized the functionality anyway, and if no one else pipes up saying that they're using it, I'd be all over deprecating the quota classes in favor of the new hotness. -- Kevin L. Mitchell signature.asc Description: This is a digitally signed message part __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
so FYI, in case people missing this spec, there is spec from John https://review.openstack.org/#/c/602201/3/specs/stein/approved/unified-limits-stein.rst@170 the roadmap of this spec is also saying deprecate the quota-class API. melanie witt 于2018年10月25日周四 上午3:54写道： > On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote: > > On 10/24/2018 10:10 AM, Jay Pipes wrote: > >> I'd like to propose deprecating this API and getting rid of this > >> functionality since it conflicts with the new Keystone /limits endpoint, > >> is highly coupled with RAX's turnstile middleware and I can't seem to > >> find anyone who has ever used it. Deprecating this API and functionality > >> would make the transition to a saner quota management system much easier > >> and straightforward. > > I was trying to do this before it was cool: > > > > https://review.openstack.org/#/c/411035/ > > > > I think it was the Pike PTG in ATL where people said, "meh, let's just > > wait for unified limits from keystone and let this rot on the vine". > > > > I'd be happy to restore and update that spec. > > Yeah, we were thinking the presence of the API and code isn't harming > anything and sometimes we talk about situations where we could use them. > > Quota classes come up occasionally whenever we talk about preemptible > instances. Example: we could create and use a quota class "preemptible" > and decorate preemptible flavors with that quota_class in order to give > them unlimited quota. There's also talk of quota classes in the "Count > quota based on resource class" spec [1] where we could have leveraged > quota classes to create and enforce quota limits per custom resource > class. But I think the consensus there was to hold off on quota by > custom resource class until we migrate to unified limits and oslo.limit. > > So, I think my concern in removing the internal code that is capable of > enforcing quota limit per quota class is the preemptible instance use > case. I don't have my mind wrapped around if/how we could solve it using > unified limits yet. > > And I was just thinking, if we added a project_id column to the > quota_classes table and correspondingly added it to the > os-quota-class-sets API, we could pretty simply implement quota by > flavor, which is a feature operators like Oath need. An operator could > create a quota class limit per project_id and then decorate flavors with > quota_class to enforce them per flavor. > > I recognize that maybe it would be too confusing to solve use cases with > quota classes given that we're going to migrate to united limits. At the > same time, I'm hesitant to close the door on a possibility before we > have some idea about how we'll solve them without quota classes. Has > anyone thought about how we can solve the use cases with unified limits > for things like preemptible instances and quota by flavor? > > Cheers, > -melanie > > [1] https://review.openstack.org/569011 > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On Wed, Oct 24, 2018 at 2:49 PM Jay Pipes wrote: > On 10/24/2018 02:57 PM, Matt Riedemann wrote: > > On 10/24/2018 10:10 AM, Jay Pipes wrote: > >> I'd like to propose deprecating this API and getting rid of this > >> functionality since it conflicts with the new Keystone /limits > >> endpoint, is highly coupled with RAX's turnstile middleware and I > >> can't seem to find anyone who has ever used it. Deprecating this API > >> and functionality would make the transition to a saner quota > >> management system much easier and straightforward. > > > > I was trying to do this before it was cool: > > > > https://review.openstack.org/#/c/411035/ > > > > I think it was the Pike PTG in ATL where people said, "meh, let's just > > wait for unified limits from keystone and let this rot on the vine". > > > > I'd be happy to restore and update that spec. > > ++ > > I think partly things have stalled out because maybe each side (keystone > + nova) think the other is working on something but isn't? > I have a Post-it on my montior to follow up with what we talked about at the PTG. AFAIK, the next steps were to use the examples we went through and apply them to nova [0] using oslo.limit. We were hoping this would do two things. First, it would expose any remaining gaps we have in oslo.limit that need to get closed before other services start using the library. Second, we could iterate on the example in gerrit as a nova review and making it easier to merge when it's working. Is that still the case and if so, how can I help? [0] https://gist.github.com/lbragstad/69d28dca8adfa689c00b272d6db8bde7 > > I'm currently working on cleaning up the quota system and would be happy > to deprecate the os-quota-classes API along with the patch series that > does that cleanup. > > -jay > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem to find anyone who has ever used it. Deprecating this API and functionality would make the transition to a saner quota management system much easier and straightforward. I was trying to do this before it was cool: https://review.openstack.org/#/c/411035/ I think it was the Pike PTG in ATL where people said, "meh, let's just wait for unified limits from keystone and let this rot on the vine". I'd be happy to restore and update that spec. Yeah, we were thinking the presence of the API and code isn't harming anything and sometimes we talk about situations where we could use them. Quota classes come up occasionally whenever we talk about preemptible instances. Example: we could create and use a quota class "preemptible" and decorate preemptible flavors with that quota_class in order to give them unlimited quota. There's also talk of quota classes in the "Count quota based on resource class" spec [1] where we could have leveraged quota classes to create and enforce quota limits per custom resource class. But I think the consensus there was to hold off on quota by custom resource class until we migrate to unified limits and oslo.limit. So, I think my concern in removing the internal code that is capable of enforcing quota limit per quota class is the preemptible instance use case. I don't have my mind wrapped around if/how we could solve it using unified limits yet. And I was just thinking, if we added a project_id column to the quota_classes table and correspondingly added it to the os-quota-class-sets API, we could pretty simply implement quota by flavor, which is a feature operators like Oath need. An operator could create a quota class limit per project_id and then decorate flavors with quota_class to enforce them per flavor. I recognize that maybe it would be too confusing to solve use cases with quota classes given that we're going to migrate to united limits. At the same time, I'm hesitant to close the door on a possibility before we have some idea about how we'll solve them without quota classes. Has anyone thought about how we can solve the use cases with unified limits for things like preemptible instances and quota by flavor? Cheers, -melanie [1] https://review.openstack.org/569011 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/24/2018 02:57 PM, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem to find anyone who has ever used it. Deprecating this API and functionality would make the transition to a saner quota management system much easier and straightforward. I was trying to do this before it was cool: https://review.openstack.org/#/c/411035/ I think it was the Pike PTG in ATL where people said, "meh, let's just wait for unified limits from keystone and let this rot on the vine". I'd be happy to restore and update that spec. ++ I think partly things have stalled out because maybe each side (keystone + nova) think the other is working on something but isn't? I'm currently working on cleaning up the quota system and would be happy to deprecate the os-quota-classes API along with the patch series that does that cleanup. -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem to find anyone who has ever used it. Deprecating this API and functionality would make the transition to a saner quota management system much easier and straightforward. I was trying to do this before it was cool: https://review.openstack.org/#/c/411035/ I think it was the Pike PTG in ATL where people said, "meh, let's just wait for unified limits from keystone and let this rot on the vine". I'd be happy to restore and update that spec. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?
Forwarding to openstack-operators per Jay. On 10/24/18 10:10, Jay Pipes wrote: > Nova's API has the ability to create "quota classes", which are > basically limits for a set of resource types. There is something called > the "default quota class" which corresponds to the limits in the > CONF.quota section. Quota classes are basically templates of limits to > be applied if the calling project doesn't have any stored > project-specific limits. > > Has anyone ever created a quota class that is different from "default"? > > I'd like to propose deprecating this API and getting rid of this > functionality since it conflicts with the new Keystone /limits endpoint, > is highly coupled with RAX's turnstile middleware and I can't seem to > find anyone who has ever used it. Deprecating this API and functionality > would make the transition to a saner quota management system much easier > and straightforward. > > Also, I'm apparently blocked now from the operators ML so could someone > please forward this there? > > Thanks, > -jay > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
