Open Stack

On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:

> 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).
>

It sounds like maybe we should have an oslo library for quotas? Somewhere
where we can share the code,but keep the operations local to each service.


>
> 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.
>

Why not centralize quota management via the python-openstackclient, what is
the benefit of getting keystone involved?


>
> 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>
>> 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>
>>> 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>
>>> 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
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Duncan Thomas
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > 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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20141007/f89e25dc/attachment.html>