Public bug reported: Tempest test test_list_servers_filter_by_zero_limit does a server list query with limit=0 which is OK with MySQL and PostgreSQL but not with DB2 since DB2's fetch-first clause doesn't support values < 1:
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0059212.html?resultof=%22%46%45%54%43%48%22%20%22%66%65%74%63%68%22%20%22%66%69%72%73%74%22%20 >From the DB2 doc: "The fetch-first-clause lets the database manager know that the application does not want to retrieve more than integer rows, regardless of how many rows there might be in the result table when this clause is not specified. An attempt to fetch beyond integer rows is handled the same way as normal end of data (SQLSTATE 02000). The value of integer must be a positive integer (not zero)." Looking at the Nova API paginate collections docs: http://docs.openstack.org/api/openstack-compute/2/content /Paginated_Collections-d1e664.html It doesn't say anything about lower bounds validation, only that over limit is a 413 HTTP error response. Otherwise the examples use limit=1. There isn't really any point of allowing the query to get down into the DB API layer just to perform a query and then remove the results, so we should just detect limit == 0 in the nova API layer and just return an empty response. ** Affects: nova Importance: Undecided Status: New ** Tags: api db2 -- 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/1296929 Title: test_list_servers_filter_by_zero_limit fails with DB2 Status in OpenStack Compute (Nova): New Bug description: Tempest test test_list_servers_filter_by_zero_limit does a server list query with limit=0 which is OK with MySQL and PostgreSQL but not with DB2 since DB2's fetch-first clause doesn't support values < 1: http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0059212.html?resultof=%22%46%45%54%43%48%22%20%22%66%65%74%63%68%22%20%22%66%69%72%73%74%22%20 From the DB2 doc: "The fetch-first-clause lets the database manager know that the application does not want to retrieve more than integer rows, regardless of how many rows there might be in the result table when this clause is not specified. An attempt to fetch beyond integer rows is handled the same way as normal end of data (SQLSTATE 02000). The value of integer must be a positive integer (not zero)." Looking at the Nova API paginate collections docs: http://docs.openstack.org/api/openstack-compute/2/content /Paginated_Collections-d1e664.html It doesn't say anything about lower bounds validation, only that over limit is a 413 HTTP error response. Otherwise the examples use limit=1. There isn't really any point of allowing the query to get down into the DB API layer just to perform a query and then remove the results, so we should just detect limit == 0 in the nova API layer and just return an empty response. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1296929/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
