yahoo-eng-team team mailing list archive

[Chris Behrens <1211702@xxxxxxxxxxxxxxxxxx>]

If you're an admin, you must be explicit in saying "I want to reach
outside of my project id" by using all_tenants=1.

** Changed in: nova
       Status: In Progress => Invalid

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

Title:
  Server list filtered by tenant_id doesn't work

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  When an admin user try to get the list of servers filtered by
  tenant_id the filter is overwritten by the admin tenant_id so  the
  actual filter specified is not used but the list is just reporting the
  the admin user's servers.

  The problem is in that in the servers API the "project_id' is defined to be equal to the context.project_id:
          if 'all_tenants' not in search_opts:
              if context.project_id:
                  search_opts['project_id'] = context.project_id

  Then in the nova/compute/api.py we have a filter_mapping to associate
  the tenant_id filter as project_id filter:

          # search_option to filter_name mapping.
          filter_mapping = {
                  'image': 'image_ref',
                  'name': 'display_name',
                  'tenant_id': 'project_id',
                  'flavor': _remap_flavor_filter,
                  'fixed_ip': _remap_fixed_ip_filter}

  because of the mapping the filter tenant_id is mapped as project_id
  then the value project_id in the dictionary is overwritten by the
  project_id filter defined at the API layer.

  My solution is basically avoid to add a filter if the same filter has been required in the original request.
  To do that the idea is, before adding a value in the serach_opts, we need to check if the key we are going to add  is present as value in the filter_mapping dict,  if so we can force the filter only if the user is not requiring the same value in the original call.

  In my opinion we should also to move all the logic about the creation
  and management of the search_opts dictionary in the API code in order
  to have a single point where the dictionary is created and the let the
  compute api code just to give results back based on the filters
  passed.

  Steps to reproduce:
  - create an instance (inst1) for the tenant_id X
  - with an admin user call the servers/detail?tenant_id=X
  - verify that the instance inst1 is not returned. (Note that if the admin user has some instances the call will get them back)

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