Open Stack

On Dec 3, 2013 6:49 PM, "John Dickinson" <me at not.mn> wrote:
>
>
> On Dec 3, 2013, at 8:05 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>
> > On 12/03/2013 10:04 AM, John Dickinson wrote:
> >> How are you proposing that this integrate with Swift's account and
container quotas (especially since there may be hundreds of thousands of
accounts and millions (billions?) of containers in a single Swift cluster)?
A centralized lookup for quotas doesn't really seem to be a scalable
solution.
> >
> > From reading below, it does not look like a centralized lookup is what
the design is. A push-change strategy is what is described, where the quota
numbers themselves are stored in a canonical location in Keystone, but when
those numbers are changed, Keystone would send a notification of that
change to subscribing services such as Swift, which would presumably have
one or more levels of caching for things like account and container
quotas...
>
> Yes, I get that, and there are already methods in Swift to support that.
The trick, though, is either (1) storing all the canonical info in Keystone
and scaling that or (2) storing some "boiled down" version, if possible,
and fanning that out to all of the resources in Swift. Both are difficult
and require storing the information in the central Keystone store.

If I remember correctly the motivation for using keystone for quotas is so
there is one easy place to set quotas across all projects.  Why not hide
this complexity with the unified client instead?  That has been the answer
we have been using for pulling out assorted proxy APIs in nova (nova
image-list volume-list) etc.

>
> >
> > Best,
> > -jay
> >
> >> --John
> >>
> >>
> >> On Dec 3, 2013, at 6:53 AM, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:
> >>
> >>> Chmouel,
> >>>
> >>> We reviewed the design of this feature at the summit with CERN and HP
teams. Centralized quota storage in Keystone is an anticipated feature, but
there are concerns about adding quota enforcement logic for every service
to Keystone. The agreed solution is to add quota numbers storage to
Keystone, and add mechanism that will notify services about change to the
quota. Service, in turn, will update quota cache and apply the new quota
value according to its own enforcement rules.
> >>>
> >>> More detailed capture of the discussion on etherpad:
> >>> https://etherpad.openstack.org/p/CentralizedQuotas
> >>>
> >>> Re this particular change, we plan to reuse this API extension code,
but extended to support domain-level quota as well.
> >>>
> >>> --
> >>> Best regards,
> >>> Oleg Gelbukh
> >>> Mirantis Labs
> >>>
> >>>
> >>> On Mon, Dec 2, 2013 at 5:39 PM, Chmouel Boudjnah <chmouel at enovance.com>
wrote:
> >>> Hello,
> >>>
> >>> I was wondering what was the status of Keystone being the central
place across all OpenStack projects for quotas.
> >>>
> >>> There is already an implementation from Dmitry here :
> >>>
> >>> https://review.openstack.org/#/c/40568/
> >>>
> >>> but hasn't seen activities since october waiting for icehouse
development to be started and a few bits to be cleaned and added (i.e: the
sqlite migration).
> >>>
> >>> It would be great if we can get this rekicked to get that for
icehouse-2.
> >>>
> >>> Thanks,
> >>> Chmouel.
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > _______________________________________________
> > 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/20131203/b707915e/attachment.html>