Open Stack

Hi Scott,

We fixed the bug keystone way in "Manila" but it was decided later that
the bug would not be fixed. Will send you the link of the fix tomorrow as
I am travelling today. BTW, keystoneclient is the only way to go as we
are not sure what keystone database is used in the background. Administrator
might have configured keystone to use LDAP.

Vaibhav


On Fri, Jun 13, 2014 at 9:44 PM, Scott Devoid <devoid at anl.gov> wrote:

> I would propose the following behavior:
>
> When os-quota-sets is updated, nova-api checks the quota tables to see
> if the quota-set for the project ID already exists in the table. If it
> does exist, then update with the new quota value. Otherwise, use
> keystoneclient to confirm that the project ID exists. If it does not
> exist, return an appropriate error to the API. Otherwise update the new
> quota value.
>
> This will catch the error except for cases where the quota table is
> already corrupted with quotas that apply to no projects.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1118066
>
> Title:
>   Nova should confirm quota requests against Keystone
>
> Status in OpenStack Compute (Nova):
>   Confirmed
>
> Bug description:
>   os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/
>   against Keystone to ensure that :tenant does exist.
>
>   POST requests to a non-existant tenant should fail with a 400 error
>   code.
>
>   GET requests to a non-existant tenant may fail with a 400 error code.
>   Current behavior is to return 200 with the default quotas. A slightly
>   incompatible change would be to return a 302 redirect to /v2/:tenant
>   /os-quota-sets/defaults in this case.
>
>   Edit (2014-01-22)
>
>   Original Description
>   --------------------
>   GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
>   returns 200 with the default quotas.
>
>   Moreover
>   POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
>   with updated quotas succeeds and that metadata is saved!
>
>   I'm not sure if this is a bug or not. I cannot find any documentation
>   on this interface.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions
>

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Nova should confirm quota requests against Keystone

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/
  against Keystone to ensure that :tenant does exist.

  POST requests to a non-existant tenant should fail with a 400 error
  code.

  GET requests to a non-existant tenant may fail with a 400 error code.
  Current behavior is to return 200 with the default quotas. A slightly
  incompatible change would be to return a 302 redirect to /v2/:tenant
  /os-quota-sets/defaults in this case.

  Edit (2014-01-22)

  Original Description
  --------------------
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions