Open Stack

Keeping the enforcement local (same way policy works today) helps limit the
fragility, big +1 there.

I also agree with Vish, we need a uniform way to talk about quota
enforcement similar to how we have a uniform policy language / enforcement
model (yes I know it's not perfect, but it's far closer to uniform than
quota management is).

If there is still interest of placing quota in keystone, let's talk about
how that will work and what will be needed from Keystone . The previous
attempt didn't get much traction and stalled out early in implementation.
If we want to revisit this lets make sure we have the resources needed and
spec(s) in progress / info on etherpads (similar to how the multitenancy
stuff was handled at the last summit) as early as possible.

Cheers,
Morgan

Sent via mobile

On Friday, October 3, 2014, Salvatore Orlando <sorlando at nicira.com> wrote:

> Thanks Vish,
>
> this seems a very reasonable first step as well - and since most projects
> would be enforcing quotas in the same way, the shared library would be the
> logical next step.
> After all this is quite the same thing we do with authZ.
>
> Duncan is expressing valid concerns which in my opinion can be addressed
> with an appropriate design - and a decent implementation.
>
> Salvatore
>
> On 3 October 2014 18:25, Vishvananda Ishaya <vishvananda at gmail.com
> <javascript:_e(%7B%7D,'cvml','vishvananda at gmail.com');>> wrote:
>
>> The proposal in the past was to keep quota enforcement local, but to
>> put the resource limits into keystone. This seems like an obvious first
>> step to me. Then a shared library for enforcing quotas with decent
>> performance should be next. The quota calls in nova are extremely
>> inefficient right now and it will only get worse when we try to add
>> hierarchical projects and quotas.
>>
>> Vish
>>
>> On Oct 3, 2014, at 7:53 AM, Duncan Thomas <duncan.thomas at gmail.com
>> <javascript:_e(%7B%7D,'cvml','duncan.thomas at gmail.com');>> wrote:
>>
>> > Taking quota out of the service / adding remote calls for quota
>> > management is going to make things fragile - you've somehow got to
>> > deal with the cases where your quota manager is slow, goes away,
>> > hiccups, drops connections etc. You'll also need some way of
>> > reconciling actual usage against quota usage periodically, to detect
>> > problems.
>> >
>> > On 3 October 2014 15:03, Salvatore Orlando <sorlando at nicira.com
>> <javascript:_e(%7B%7D,'cvml','sorlando at nicira.com');>> wrote:
>> >> Hi,
>> >>
>> >> Quota management is currently one of those things where every openstack
>> >> project does its own thing. While quotas are obviously managed in a
>> similar
>> >> way for each project, there are subtle differences which ultimately
>> result
>> >> in lack of usability.
>> >>
>> >> I recall that in the past there have been several calls for unifying
>> quota
>> >> management. The blueprint [1] for instance, hints at the possibility of
>> >> storing quotas in keystone.
>> >> On the other hand, the blazar project [2, 3] seems to aim at solving
>> this
>> >> problem for good enabling resource reservation and therefore
>> potentially
>> >> freeing openstack projects from managing and enforcing quotas.
>> >>
>> >> While Blazar is definetely a good thing to have, I'm not entirely sure
>> we
>> >> want to make it a "required" component for every deployment. Perhaps
>> single
>> >> projects should still be able to enforce quota. On the other hand, at
>> least
>> >> on paper, the idea of making Keystone "THE" endpoint for managing
>> quotas,
>> >> and then letting the various project enforce them, sounds promising -
>> is
>> >> there any reason for which this blueprint is stalled to the point that
>> it
>> >> seems forgotten now?
>> >>
>> >> I'm coming to the mailing list with these random questions about quota
>> >> management, for two reasons:
>> >> 1) despite developing and using openstack on a daily basis I'm still
>> >> confused by quotas
>> >> 2) I've found a race condition in neutron quotas and the fix is not
>> trivial.
>> >> So, rather than start coding right away, it might probably make more
>> sense
>> >> to ask the community if there is already a known better approach to
>> quota
>> >> management - and obviously enforcement.
>> >>
>> >> Thanks in advance,
>> >> Salvatore
>> >>
>> >> [1] https://blueprints.launchpad.net/keystone/+spec/service-metadata
>> >> [2] https://wiki.openstack.org/wiki/Blazar
>> >> [3] https://review.openstack.org/#/q/project:stackforge/blazar,n,z
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> <javascript:_e(%7B%7D,'cvml','OpenStack-dev at lists.openstack.org');>
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Duncan Thomas
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> <javascript:_e(%7B%7D,'cvml','OpenStack-dev at lists.openstack.org');>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <javascript:_e(%7B%7D,'cvml','OpenStack-dev at lists.openstack.org');>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/3b0cdd26/attachment-0001.html>