Mandatory API Query Limits¶
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/ceilometer/+spec/mandatory-api-limit
Currently, Ceilometer’s api allows users to query for as much or as little data as they desire. They are also allowed to query for everything no matter the size of results.
Problem description¶
Allowing the ability to have return the entire world of data is not a realistic use case. While it is easier in theory to query for everything, in reality, this is not viable as it puts a lot of strain on CPU and memory to manage all the data required. In addition, these queries take a significant amount of time to calculate and will always time out even if enough resources are available to the system.
As Ceilometer intends to remove unused pagination, another form of query restriction is required.
Proposed change¶
Mandatory limits must be enforced on queries, whether it be a limit value. If neither value is provided, a default restriction of 100 will be applied. This behaves similarly to other dbs such as ElasticSearch which limit the number of results returned if no restrictions are provided.
Users are still allowed to query the entire set of data if they choose to, but instead of implicitly doing so as it currently functions, users will need to explicitly do so.
These restrictions will apply to both events and meters api.
Alternatives¶
Nothing, and let users blame Ceilometer for insane queries.
Data model impact¶
None
REST API impact¶
All GET queries will require a limit value. If none is given, a default of 100 will be applied.
Security impact¶
None
Pipeline impact¶
None
Other end user impact¶
A limit value is required to get data as expected. If none is provided, the returned results may be truncated. A warning will be logged whenever the default limit is applied.
Performance/Scalability Impacts¶
This will limit the load created by unintentional large queries.
Other deployer impact¶
A new option will be defined to allow operators control of what the default return limit is.
Developer impact¶
Unit tests need to be written to consider this limit.
Implementation¶
Assignee(s)¶
- Primary assignee:
gordc
- Other contributors:
None
- Ongoing maintainer:
None
Work Items¶
Add option to control default limit value
Apply limit check to meter queries and fix UT
Apply limit check to event queries and fix UT
Update docs
Future lifecycle¶
We can derive a query link which returns next set of data based on last timestamp value of returned set.
Dependencies¶
None
Testing¶
Unit test to test default limits are applied.
Documentation Impact¶
This may be a breaking change to some – Ceilometer will probably be already broken to them. That said, this will need to be publicised.
