Edit project validates quota against resources used in current project instead of edited project.

[Jakub Josef]

Hi,
if we tried to add users in project using horizon and that project is different than edited project. Saving can fail on quetas exceed, because current amount of quotas was taken from selected project instead of form-related project.

Maybe you should use instance.project instead of request.project.

Steps to reproduce:
Select some project with some allocated RAM and VCPUS.
Edit a project using admin interface, project must be other then selected.
Set a smaller quotas than selected project already allocated.
Saving is forbidden due to lesser quotas than enforced in the form - this is because quotas was computed from bad project.

[Gary W. Smith (gary-w-smith)]

Verified in Pike.

[David Lyle (david-lyle)]

The reproduction steps are misleading. I believe you are referring to the projects panel in the identity dashboard?

[Gary W. Smith (gary-w-smith)]

Alternate way to reproduce:
- Login as admin, choose demo project
- Go to Project > Compute > Instances and launch 2 compute instances
- Go to Identity > Projects. Use Modify Quota on alt_demo project (or any project other than demo)
- Change Instances to 1 and hit Save

[Jakub Josef (jakob92)]

Sorry guys i wrote this report at very busy day in office. Gary's steps are better to understand. In the other words the problem is inside the validation process of quotas. There have to be some code for verify the requested quotas can be applied for that project.
This code comparing new quotas configuration with current state of tenant (project). But UI selected project is used for that comparison instead of current settings related project.

Good example can be a new empty project. If you want to set low quotas and you have selected some used project in UI dropdown, the configuration fails with error like: Quotas cannot be lower than actual project state. But related project is new and empty.

[Ying Zuo (yingzuo)]

I was able to reproduce this issue with these steps:

1) Go to project/instances panel. Make sure there are more than one instances and I have 8 instances.
2) Go to identity/projects panel. Create a new project with the default quotas.
3) Click the modify quotas action on the newly created project and try to set the quota for instances as 1.
4) Error "Quota value(s) cannot be less than the current usage value(s): 8 Instances used." is shown on the modal.

[David Lyle (david-lyle)]

Ok I was able to reproduce this. Looking into it more.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/510188

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/510188
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=33dc94079cc25128998d2f339e664a775ce82396
Submitter: Zuul
Branch: master

commit 33dc94079cc25128998d2f339e664a775ce82396
Author: David Lyle <email address hidden>
Date: Fri Oct 6 10:44:03 2017 -0600

    Correct quota usage check for instances

    Previously, updating the quota value for instance on a project that
    the user was not currently scoped to would validate the new quota
    value by comparing with the usage of the currently scoped project.
    The cause of this error was an incorrect use of the server list
    parameters.

    According to the comment in nova source:
    https://github.com/openstack/nova/blob/d43d1d673403c1bf9e2ffd94d7a711956a3506de/nova/api/openstack/compute/servers.py#L277-L280
    and the comments in this bug:
    https://bugs.launchpad.net/nova/+bug/1185290

    indicate that the tenant_id or project_id flag cannot be used without
    the --all-tenants flag.

    The fix involves passing the --all-tenants flag when querying instance usage
    for any project the user is not currently scoped to. It also removes the
    passing of the tenant_id flag when querying the current project.

    Tests were also updated to match the new behavior by not passing the
    tenant_id to the API call to list servers where the target project is
    the currently scoped project.

    Change-Id: Iee06bc1c8ccd50f595f4cb274f956c13495c8494
    Closes-Bug: #1713724

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/horizon 13.0.0.0b2 development milestone.

[Dr. Jens Harbott (j-harbott)]

This also affects ocata and pike (even newton it seems). Can the fix be backported at least for pike?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/534348

[Akihiro Motoki (amotoki)]

A backport has been proposed to pike.
Backporting patches is a manual process and we just forgot it. Thanks for the reminder.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/534348
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=2c4c4aa77a092d673f90ea5e73599fc43b6ec7be
Submitter: Zuul
Branch: stable/pike

commit 2c4c4aa77a092d673f90ea5e73599fc43b6ec7be
Author: David Lyle <email address hidden>
Date: Fri Oct 6 10:44:03 2017 -0600

    Correct quota usage check for instances

    Previously, updating the quota value for instance on a project that
    the user was not currently scoped to would validate the new quota
    value by comparing with the usage of the currently scoped project.
    The cause of this error was an incorrect use of the server list
    parameters.

    According to the comment in nova source:
    https://github.com/openstack/nova/blob/d43d1d673403c1bf9e2ffd94d7a711956a3506de/nova/api/openstack/compute/servers.py#L277-L280
    and the comments in this bug:
    https://bugs.launchpad.net/nova/+bug/1185290

    indicate that the tenant_id or project_id flag cannot be used without
    the --all-tenants flag.

    The fix involves passing the --all-tenants flag when querying instance usage
    for any project the user is not currently scoped to. It also removes the
    passing of the tenant_id flag when querying the current project.

    Tests were also updated to match the new behavior by not passing the
    tenant_id to the API call to list servers where the target project is
    the currently scoped project.

    Change-Id: Iee06bc1c8ccd50f595f4cb274f956c13495c8494
    Closes-Bug: #1713724
    (cherry picked from commit 33dc94079cc25128998d2f339e664a775ce82396)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/horizon 12.0.3 release.

[Annie Melen (anniemelen)]

Hello!

I've just encountered the same issue in openstack-dashboard 13.0.1. Why it wasn't fixed in Queens Release?

[Jahab Thalib (jagab)]

What the hell you talking about, backstopped! This bug is fixed in Pike.
Please test it better, attach the logs!

[Annie Melen (anniemelen)]

Jahab,
I definitely should explain what the hell I'm talking about.

Steps to reproduce (via Horizon, of course):

1. Create new project, new user with admin credentials, set new project as primary for new user:
https://pasteboard.co/HTvmbcG.jpg

2. Login as new user. Populate new (primary) project with few instances and volumes:
https://pasteboard.co/HTvnD0i.jpg

3. Create test project with default quotas.

4. Try to modify test project quotas, setting 'volumes', 'gigabytes' values lower then your primary project current usage:
https://pasteboard.co/HTvqFR5.jpg

5. Try to modify test project quotas, setting 'instances', 'vcpus', 'ram' values lower then your primary project current usage:
https://pasteboard.co/HTvr4HR.jpg

6. Login as other user with admin credentials, but with blank primary_project field. Try to modify test project quotas the way above. It will be OK.

My environment:
Ubuntu 16.04 LTS, Queens Release, openstack-dashboard 13.0.1

I've never seen such behavior when setting quotas the way above via command line, so it's obviously the bug in Horizon.
What kind of logs do you need?

[Dr. Jens Harbott (j-harbott)]

I tested with the same environment, Ubuntu Queens UCA, exact version of openstack-dashboard is 3:13.0.1-0ubuntu3~cloud0.

I can reproduce the issue at step 5., trying to change volume quota, but not for compute quota step 4. Looking at the patch, it seems that it only changed quota retrieval from Nova and not from Cinder.

[Dr. Jens Harbott (j-harbott)]

Verified that the issue regarding volume quota is still present in master, but since I cannot modify the status, I created https://bugs.launchpad.net/horizon/+bug/1810309 now.

[Annie Melen (anniemelen)]

Dr. Jens,
thanks for your help!

You're right, the issue is regarding only to Cinder quotas. I've recently checked it with the openstack-dashboard 3:13.0.1-0ubuntu4~cloud0 version.