yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: nova
       Status: Fix Committed => Fix Released

** Changed in: nova
    Milestone: None => juno-1

-- 
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):
  Fix Released

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