I validated today with openstackclient 1.7.0 that you can't show quotas for a project that doesn't exist:
stack@client:~/devstack$ openstack quota show randomtext
Tenant ID: randomtext does not exist. (HTTP 404) (Request-ID: req-cc9354ea-5935-45db-be60-b86aaf0a20ea)
And I validated that with the v2.1 API you can't request a quota update on non-standard resources:
{"badRequest": {"message": "Invalid input for field/attribute quota_set. Value: {u'foo': 20, u'force': True}. Additional properties are not allowed (u'foo' was unexpected)", "code": 400}}
So we need to do something about that. I see two options:
1. quota-sets.update should only attempt to update quota on existing resources - if objects.Quotas.update_limit fails with a not found, we return 404 on the response. We don't try to create quotas automatically if they don't exist. However, as part of this we'd need to add a new quotas-sets.create API since update is handling both create and update today. This would require a microversion change since it's not backward compatible.
2. We could change quota-sets.update to try and update first and if we get a 404, then we validate the projectid against the identity service before calling objects.Quotas.create_limit. That would at least narrow the performance impact of validating the projectid against keystone in the request.
I validated today with openstackclient 1.7.0 that you can't show quotas for a project that doesn't exist:
stack@client: ~/devstack$ openstack quota show randomtext 5935-45db- be60-b86aaf0a20 ea)
Tenant ID: randomtext does not exist. (HTTP 404) (Request-ID: req-cc9354ea-
And I validated that with the v2.1 API you can't request a quota update on non-standard resources:
{"badRequest": {"message": "Invalid input for field/attribute quota_set. Value: {u'foo': 20, u'force': True}. Additional properties are not allowed (u'foo' was unexpected)", "code": 400}}
Because the jsonschema prevents that:
https:/ /github. com/openstack/ nova/blob/ master/ nova/api/ openstack/ compute/ schemas/ quota_sets. py#L28
However, you can create a nova.quotas table entry with an invalid projectid:
http:// paste.openstack .org/show/ 475511/
So we need to do something about that. I see two options:
1. quota-sets.update should only attempt to update quota on existing resources - if objects. Quotas. update_ limit fails with a not found, we return 404 on the response. We don't try to create quotas automatically if they don't exist. However, as part of this we'd need to add a new quotas-sets.create API since update is handling both create and update today. This would require a microversion change since it's not backward compatible.
2. We could change quota-sets.update to try and update first and if we get a 404, then we validate the projectid against the identity service before calling objects. Quotas. create_ limit. That would at least narrow the performance impact of validating the projectid against keystone in the request.