yahoo-eng-team team mailing list archive

[Stephen Finucane <2089403@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

The 'openstack limit list' command exposes the limit list ('GET
/v3/limits') API. Both the API and command indicate support for
'project-id' and 'domain-id' filters. However, if using these with a
project-scoped or domain-scoped filter the keystone also adds filters
for the respective project or domain ID from the token, resulting in a
query like the below (using '--project-id' with a project-scoped token):

  SELECT `limit`.internal_id AS limit_internal_id, `limit`.id AS limit_id, `limit`.project_id AS limit_project_id, `limit`.domain_id AS limit_domain_id, `limit`.resource_limit AS limit_resource_limit, `limit`.description AS limit_description, `limit`.registered_limit_id AS limit_registered_limit_id
  FROM `limit` LEFT OUTER JOIN registered_limit ON registered_limit.id = `limit`.registered_limit_id
  WHERE `limit`.project_id = %(project_id_1)s AND `limit`.project_id = %(project_id_2)s

This means the the filters must exactly match what's in the token or
keystone will attempt to match of two different values resulting in an
empty list. This is a massive gotcha that is not documented anywhere,
leading me to think this is not the expected behaviour and we should
instead only retrieve information from the token if the user didn't
provide any filters.

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2089403

Title:
  Impossible to filter limits by project ID

Status in OpenStack Identity (keystone):
  New

Bug description:
  The 'openstack limit list' command exposes the limit list ('GET
  /v3/limits') API. Both the API and command indicate support for
  'project-id' and 'domain-id' filters. However, if using these with a
  project-scoped or domain-scoped filter the keystone also adds filters
  for the respective project or domain ID from the token, resulting in a
  query like the below (using '--project-id' with a project-scoped
  token):

    SELECT `limit`.internal_id AS limit_internal_id, `limit`.id AS limit_id, `limit`.project_id AS limit_project_id, `limit`.domain_id AS limit_domain_id, `limit`.resource_limit AS limit_resource_limit, `limit`.description AS limit_description, `limit`.registered_limit_id AS limit_registered_limit_id
    FROM `limit` LEFT OUTER JOIN registered_limit ON registered_limit.id = `limit`.registered_limit_id
    WHERE `limit`.project_id = %(project_id_1)s AND `limit`.project_id = %(project_id_2)s

  This means the the filters must exactly match what's in the token or
  keystone will attempt to match of two different values resulting in an
  empty list. This is a massive gotcha that is not documented anywhere,
  leading me to think this is not the expected behaviour and we should
  instead only retrieve information from the token if the user didn't
  provide any filters.

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