This session will include the following subject(s):
Improve Ceilometer test strategy:
Ceilometer has a quite large test base, but it is still not enough or not good enough.
The goal of this session once is to give a brief overview about the issues with testing in Ceilometer, including the missing areas, not well built-up strategy, issues with the testing libraries or even with the test skipping logic. After having a picture about the problems, we can discuss how to improve our test code and what kind of strategies/directions should be followed.
Some highlights from the current experiences:
* The coverage of Ceilometer's code base, based on the lines of code that are covered, has a quite good value (above 85%). But it is still easy to find uncovered branches in every part of the code. Because of the uncovered branches, it is harder to refactor the code or add new functionality, that affects the existing ones, without possibly breaking some working features.
* Another more high-level issue pertains to the potential pitfalls around testing with highly artificial datasets, and potential strategies for exercising the metering pipeline against a more realistic and larger quantum of measurements.
* Finally, we have had ongoing problems with landing substantial coverage in Tempest, largely due to performance issues in the sqlalchemy driver. While continued coverage for this driver is crucial to give deployers with AGPL concerns an alternative to mongodb, we also need a strategy to ensure that mongo itself is adequately tested in the gate (given that certain distros recommend this driver as the only one currently production-ready). The blocker is that Ceilometer depends on features in mongodb 2.4, whereas short of enabling the Ubuntu Cloud Archive, the gate running on Precise is restricted to version 2.0.4. One approach to discuss would be to introduce a mongo-based Tempest variant (in the style of the postgres variant) running on CentOS 7 or Fedora 20. We should also revisit the idea mooted in Portland, to use decorators applied to existing resource-lifecycle testcases to inject additional ceilometer assertions.
Co-proposed with Eoghan Glynn
(Session proposed by Ildiko Vancsa)
New gate jobs for coverage and spelling:
To ensure the acceptable level of code coverage in Ceilometer and also to avoid the periodical misspelling correction patches on review, two new gate jobs were proposed for Ceilometer.
The goal of this session is to identify an efficient way for implementing the proposed gate jobs and also for identifying any additional need regarding to improve the gate jobs for Ceilometer.