On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg <morgan.fainb...@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 <sorla...@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 <vishvana...@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.tho...@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 <sorla...@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@lists.openstack.org >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> > >>> > >>> > >>> > -- >>> > Duncan Thomas >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
