Mailing List Archive

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On Wed, Oct 24, 2018 at 2:49 PM Jay Pipes <jaypipes@gmail.com> 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-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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.bhor@linecorp.com

?

-----Original Message-----
From: "Kevin L. Mitchell"<klmitch@mit.edu>
To: "OpenStack Development Mailing List (not for usage questions)"<openstack-dev@lists.openstack.org>; "openstack-operators@lists.openstack.org"<openstack-operators@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 <klmitch@mit.edu>


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

melanie witt <melwittt@gmail.com> wrote on 10/25/2018 02:14:40 AM:
> On Thu, 25 Oct 2018 14:12:51 +0900, $B%\!<%"%G%#%M%7%e(B[bhor Dinesh] wrote:
> > We were having a similar use case like *Preemptible Instances* called
as
> > *Rich-VM$B!G(Bs* 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