Get volumes with limit and filters does not work

Bug #1287813 reported by Steven Kaufer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
Fix Released
High
Steven Kaufer

Bug Description

All filtering is done after the volumes are retrieved from the database in the API.get_all function in /cinder/volume/api.py. Therefore, the usage combination of filters and limit will only work if all volumes matching the filters are in the page of data being retrieved from the database.

For example, assume that all of the volumes with a name of "foo" would be retrieved from the database starting at index 100 and that you query for all volumes with a name of "foo" while specifying a limit of 50. In this case, the query would yield 0 results since the filter did not match any of the first 50 entries retrieved from the database.

In order to re-create, first create some volumes:

cinder create --display_name group_one 1
cinder create --display_name group_one 2
cinder create --display_name group_two 1
cinder create --display_name group_two 2
cinder create --display_name group_two 1 --metadata key1=val1

When querying volumes with the following parameters, the first 2 volumes (ie, named 'group_one') will always be returned and the filters will be applied to them only:

/volumes?sort_key=created_at&sort_dir=asc&limit=2

Therefore, the following queries yield 0 results even though volumes that match exist:

/volumes?sort_key=created_at&sort_dir=asc&limit=2&name=group_two
/volumes?sort_key=created_at&sort_dir=asc&limit=2&metadata={'key1': 'val1'}

Steven Kaufer (kaufer)
Changed in cinder:
assignee: nobody → Steven Kaufer (kaufer)
Revision history for this message
Jay Bryant (jsbryant) wrote :

Have talked to Steven about this issue and walked through the proposed solution. This is something we should get fixed in Icehouse as filtering really isn't working as it should right now.

Changed in cinder:
importance: Undecided → High
milestone: none → icehouse-3
milestone: icehouse-3 → icehouse-rc1
status: New → Triaged
Mike Perez (thingee)
tags: added: havana-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (master)

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

Changed in cinder:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (master)

Reviewed: https://review.openstack.org/79120
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=10dcf874ac16e410993d9d929a89bb07305f46da
Submitter: Jenkins
Branch: master

commit 10dcf874ac16e410993d9d929a89bb07305f46da
Author: Steven Kaufer <email address hidden>
Date: Fri Mar 7 23:01:51 2014 +0000

    get volumes with limit and filters does not work

    The /volumes and /volumes/detail REST APIs support filtering. Currently,
    all filtering is done after the volumes are retrieved from the database
    in the API.get_all function in /cinder/volume/api.py. Therefore, the usage
    combination of filters and limit will only work if all volumes matching
    the filters are in the page of data being retrieved from the database.

    For example, assume that all of the volumes with a name of "foo" would be
    retrieved from the database starting at index 100 and that you query for
    all volumes with a name of "foo" while specifying a limit of 50. In this
    case, the query would yield 0 results since the filter did not match any of
    the first 50 entries retrieved from the database.

    This patch removes all filtering from the volume API layer and moves it
    into the DB layer.

    Test cases were added to verify filtering at the DB level.

    Change-Id: Ia084e1f4cf59ea39bf8a0a36686146a315168cbb
    Closes-bug: 1287813

Changed in cinder:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in cinder:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in cinder:
milestone: icehouse-rc1 → 2014.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.