Where a limit is not explicitly specified on a ceilometer API query, a reasonable default value should be applied in order to avoid returning an infeasibly large result set.
We can test this by manipulating a new configuration setting in the api group: default_api_return_limit The default value is 100. So we need to test: * that default is used when there are more than 100 results * that changing the config has the expected result * that passing an explicit limit on a query overrides the config value We need a query that will return more than 100 results, these instructions assume we already have an installation running, with at least one instance and a short polling interval, as described in https://bugzilla.redhat.com/show_bug.cgi?id=1258912 Once that has been running we can make queries about the resource: * confirm the default is being followed: brick:~ $ ceilometer sample-list -q resource_id=$INSTANCE|grep -c $INSTANCE 100 * confirm there are more results than that and the limit can be override: brick:~ $ ceilometer sample-list -q resource_id=$INSTANCE --limit 9999|grep -c $INSTANCE 1845 * confirm changing the config changes the limit: * change /etc/ceilometer/ceilometer.conf to set 'default_api_return_limit' in the 'api' section to 10 * restart the ceilometer api (if using mod wsgi, reload the httpd service) brick:~ $ ceilometer sample-list -q resource_id=$INSTANCE|grep -c $INSTANCE 10 Making other types of queries (meter-list, resource-list) will confirm the feature is in use on other query types. Note, however, that at the time of this writing I've just discovered a bug in python-ceilometerclient that prevents the --limit keyword from working on meter-list and resource-list (and perhaps others). I'll report that bug and by the time this testing scenario needs to be used it ought to be fixed.
I was using ceilometerclient 1.4.0, the --limit problem is corrected in 1.5.0 (released 2015.09.09)
Verified according test plan. ceilometer*-5.0.2-1.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0603.html