On a cloud with a large number of tenants, this is going to involve a large number of API calls. I'd suggest you put a spec into cinder to add an API call for getting the totals straight out of the DB - it should be easy enough to add.
On 18 December 2015 at 20:35, Timur Sufiev <tsuf...@mirantis.com> wrote: > Matt, > > actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call > that I needed. Now I know how to retrieve Cinder quota usage info > per-tenant, seems that to retrieve the same info cloud-wide I should sum up > all the available tenant usages. > > With Cinder quota usages being sorted out, my next goal is Nova and > Neutron. As for Neutron, there are plenty of quota-related calls I'm going > to play with next week, perhaps there is something suitable for my use > case. But as for Nova, I haven't found something similar to 'usage' of > cinderclient call, so help from someone familiar with Nova is very > appreciated :). > > [0] > https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36 > > On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann <mrie...@linux.vnet.ibm.com> > wrote: > >> >> >> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote: >> > Hi Timur, >> > >> > Did you try this Cinder API [1]? Here [2] is cinderclient output. >> > >> > >> > >> > [1] >> > >> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33 >> > [2] http://paste.openstack.org/show/482225/ >> > >> > Regards, >> > Ivan Kolodyazhny, >> > http://blog.e0ne.info/ >> > >> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev <tsuf...@mirantis.com >> > <mailto:tsuf...@mirantis.com>> wrote: >> > >> > Hello, folks! >> > >> > I'd like to initiate a discussion of the feature request I'm going >> > to make on behalf of Horizon to every core OpenStack service which >> > supports Quota feature, namely Cinder, Nova and Neutron. >> > >> > Although all three services' APIs support special calls to get >> > current quota limitations (Nova and Cinder allows to get and update >> > both per-tenant and default cloud-wide limitations, Neutron allows >> > to do it only for per-tenant limitations), there is no special call >> > in any of these services to get current per-tenant usage of quota. >> > Because of that Horizon needs to get, say for 'volumes' quota, a >> > list of Cinder volumes in the current tenant and then just calculate >> > its length [1]. When there are really a lot of entities in tenant - >> > instances/volumes/security groups/whatever - all this calls sum up >> > and make rendering pages in Horizon much more slower than it could >> > be. Is it possible to provide special API calls to alleviate this? >> > >> > [1] >> > >> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350 >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > < >> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> I think Timur is asking for a way to filter on only certain resources >> for quota usage/limits, like volumes in cinder or instances in nova, >> rather than getting back all resource usage/limits per tenant. >> >> Is that correct, Timur? >> >> While it's possible to add this, I'm not sure how much time it's >> actually going to save in the DB query time to get the quota information >> for a tenant. >> >> Anyway, it's an API change so it would require a spec for nova which >> means we wouldn't be getting to that until at least N since we're in >> spec freeze for mitaka. >> >> -- >> >> Thanks, >> >> Matt Riedemann >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
