yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem@xxxxxxxxxx>]

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