Volume Quota calls going to Nova instead of Cinder

Bug #1095876 reported by Gloria Gu
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Invalid
Undecided
Unassigned
Folsom
Won't Fix
Undecided
Unassigned

Bug Description

openstack is folsom
using cinder volume

 how to reproduce:

login as admin
create a project and assign a 1000 for the volume quota
create a user with admin role in horizon and assign that project
login as that user
try to create more than 10 volumes
it will complain about exceeding the limit

workaround

in cinder.conf add the following line:

quota_volumes=1000
quota_gigabytes=100000

restart cinder...then it is ok.

Revision history for this message
Anthony Goddard (agoddard) wrote :

in addition to modifying the cinder.conf, you can also use the cinder command in place of the nova command.
If you run nova quota-update (tenant-id) --gigabytes=100000, you will see the quota updated in nova, but running cinder quota-show (tenant-id) will not reflect this.

running cinder quota-update (tenant-id) --gigabytes=100000 will also work.

horizon should probably use the cinder quota and not the nova quota in the UI so it's not misleading.

Revision history for this message
Gabriel Hurley (gabriel-hurley) wrote :

I've actually heard this bug reported before but the report never got filed upstream. The fix is to use the correct cinder API call when cinder is present instead of the Nova API call.

Changed in horizon:
importance: Undecided → High
milestone: none → grizzly-3
status: New → Confirmed
summary: - will not honor large volume quota for a project
+ Volume Quota calls going to Nova instead of Cinder
Revision history for this message
Gabriel Hurley (gabriel-hurley) wrote :

This was fixed in master, the bug report is for Folsom.

Changed in horizon:
importance: High → Undecided
milestone: grizzly-3 → none
status: Confirmed → Invalid
Revision history for this message
Gabriel Hurley (gabriel-hurley) wrote :

This has been all fixed in Grizzly, but the scope involved in backporting all the patches that were necessary makes me disinclined to do so. It would require backporting all of the following to avoid rehashing the entire trail of issues that had to be resolved for this:

https://github.com/openstack/horizon/commit/cdcd8e3df6ee143cc96b5e2a2d849e9ae8e86148
https://github.com/openstack/horizon/commit/dfe0cf8e26fed4c5e83964af620ca80df4bb6f74
https://github.com/openstack/horizon/commit/4c88b9b5977c50525771876b2a8624fa586b8f6e

Even though it is a nuisance in Folsom, this is simply too large a backport, IMHO.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.