create project validates quota usage against the current project

[Doug Fish]

When creating a new project under Admin->Identity->Create project, it seems that validation for quota values provided by the new project are validated against the usage of the current project. I've verified this behavior for volumes, instances, and virtual CPUs.

To see the problem.
* create 5 instances in the current project
* create a new project (Admin->Identity->Create project) and on the Quotas tab, set the new projects Instance quota to 4.
On create this message will be displayed:
Quota value(s) cannot be less than the current usage value(s): 5 Instances used

There is no reason the *current* usage should be compared to a *new* project.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/129037
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=193d40a41472adc6c27e18256524afb2dacb9156
Submitter: Jenkins
Branch: master

commit 193d40a41472adc6c27e18256524afb2dacb9156
Author: Sam Betts <email address hidden>
Date: Thu Oct 16 14:20:36 2014 +0100

    Pass correct project ID to get tenant_usages

    The current implementation of tenant_quota_usages did not allow for
    queries regarding projects that were not the currently active project,
    this meant that when an admin went to edit or create a project it tried
    to verify the usages against the wrong project. This patch adds the
    code for passing a project id to the tenant_quota_usages function so
    that the usages can be fetched for a specific project, as well as
    removes the need for usage validation on creation of a new project.

    Change-Id: I3ec84d14c8be7e3aae066119e963c4093f8aa345
    Closes-Bug: 1380701

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/161182

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/161182
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=947bc63977134472eaf0e7fb5ca2f1b2bab3836a
Submitter: Jenkins
Branch: stable/juno

commit 947bc63977134472eaf0e7fb5ca2f1b2bab3836a
Author: Sam Betts <email address hidden>
Date: Wed Mar 4 10:22:24 2015 +0000

    Pass correct project ID to get tenant_usages

    The current implementation of tenant_quota_usages did not allow for
    queries regarding projects that were not the currently active project,
    this meant that when an admin went to edit or create a project it tried
    to verify the usages against the wrong project. This patch adds the
    code for passing a project id to the tenant_quota_usages function so
    that the usages can be fetched for a specific project, as well as
    removes the need for usage validation on creation of a new project.

    (cherry picked from commit 193d40a41472adc6c27e18256524afb2dacb9156)

    Change-Id: I3ec84d14c8be7e3aae066119e963c4093f8aa345
    Closes-Bug: 1380701

[Jacolex (jacolex)]

Hello
I've been experiencing this issue again in Ocata. The same error and values are validating against current project.

[Radoslaw Poplawski (rpoplawski)]

I can confirm this bug is present in Ocata.

[György Szombathelyi (gyurco)]

Yepp, popped up in Ocata.

[zibort (zibort)]

I've found out it today in Newton.

[Radomir Dopieralski (deshipu)]

I looks like we have a regression on this. It was added by making the action respect the project_id passed from the form, but today the form no longer has a project_id field, so it again checks the quotas against user's default project.

[Radomir Dopieralski (deshipu)]

Actually, quotas.tenant_quota_usages() is returning the usages for the default project, even though it has correct tenant_id passed.

[Radomir Dopieralski (deshipu)]

Looks like this API call:

       instances, has_more = nova.server_list(
            request, search_opts={'tenant_id': tenant_id, 'all_tenants': True})

returns all instances for all tenants, not just the ones that match the tenant_id.

[Radomir Dopieralski (deshipu)]

That call looks like this on Newton:

novaclient.v2.client REQ: curl -g -i 'http://192.168.122.185:8774/v2.1/500a8db1a3304d9ab22bac46494ca04e/servers/de
tail?project_id=500a8db1a3304d9ab22bac46494ca04e&tenant_id=63f322ecef0249c6ba56594fc73edc5e' -X GET -H "Accept: application/json" -H "User-Agent: pyth
on-novaclient" -H "X-Auth-Project-Id: 500a8db1a3304d9ab22bac46494ca04e" -H "X-Auth-Token: {SHA1}7b556b9298c4825b040ba5a324d853d1526496fc"
2017-12-19 01:47:29,273 29405 DEBUG novaclient.v2.client RESP: [200] {'Content-Length': '3047', 'X-Compute-Request-Id': 'req-dca03931-09fb-4fe0-acee-b
19e157a423c', 'Vary': 'OpenStack-API-Version, X-OpenStack-Nova-API-Version', 'Openstack-Api-Version': 'compute 2.1', 'Connection': 'keep-alive', 'X-Op
enstack-Nova-Api-Version': '2.1', 'Date': 'Tue, 19 Dec 2017 01:47:29 GMT', 'Content-Type': 'application/json'}
RESP BODY: {"servers": [{"OS-EXT-STS:task_state": null, "addresses": {}, "links": [{"href": "http://192.168.122.185:8774/v2.1/500a8db1a3304d9ab22bac46
494ca04e/servers/a0eb0916-4fe3-46b6-bb82-5c8ef3286e43", "rel": "self"}, {"href": "http://192.168.122.185:8774/500a8db1a3304d9ab22bac46494ca04e/servers
/a0eb0916-4fe3-46b6-bb82-5c8ef3286e43", "rel": "bookmark"}], "image": "", "OS-EXT-STS:vm_state": "error", "OS-EXT-SRV-ATTR:instance_name": "instance-0
0000001", "OS-SRV-USG:launched_at": null, "flavor": {"id": "1", "links": [{"href": "http://192.168.122.185:8774/500a8db1a3304d9ab22bac46494ca04e/flavo
rs/1", "rel": "bookmark"}]}, "id": "a0eb0916-4fe3-46b6-bb82-5c8ef3286e43", "user_id": "affa3ba92c4a480faa35b9a3799a8bc6", "OS-DCF:diskConfig": "AUTO",
 "accessIPv4": "", "accessIPv6": "", "OS-EXT-STS:power_state": 0, "OS-EXT-AZ:availability_zone": "nova", "metadata": {}, "status": "ERROR", "updated":
 "2017-12-19T00:47:59Z", "hostId": "", "OS-EXT-SRV-ATTR:host": null, "OS-SRV-USG:terminated_at": null, "key_name": null, "OS-EXT-SRV-ATTR:hypervisor_h
ostname": null, "name": "xxx", "created": "2017-12-19T00:47:30Z", "tenant_id": "500a8db1a3304d9ab22bac46494ca04e", "os-extended-volumes:volumes_attach
ed": [{"id": "6a4c7d08-2eee-42e8-a9f0-fbff3cbaa3d3"}], "fault": {"message": "No valid host was found. There are not enough hosts available.", "code":
500, "details": " File \"/usr/lib/python2.7/site-packages/nova/conductor/manager.py\", line 496, in build_instances\n context, request_spec, filte
r_properties)\n File \"/usr/lib/python2.7/site-packages/nova/conductor/manager.py\", line 567, in _schedule_instances\n hosts = self.scheduler_cli
ent.select_destinations(context, spec_obj)\n File \"/usr/lib/python2.7/site-packages/nova/scheduler/utils.py\", line 370, in wrapped\n return func
(*args, **kwargs)\n File \"/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py\", line 51, in select_destinations\n return self.que
ryclient.select_destinations(context, spec_obj)\n File \"/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py\", line 37, in __run_meth
od\n return getattr(self.instance, __name)(*args, **kwargs)\n File \"/usr/lib/python2.7/site-packages/nova/scheduler/client/query.py\", line 32, i
n select_destinations\n return self.scheduler_rpcapi.select_destinations(cont...

[Radomir Dopieralski (deshipu)]

Looks like this is fixed by https://bugs.launchpad.net/horizon/+bug/1713724