diary-14aug2013.md

14 Aug 2013

Ceilometer meeting

We discussed the blueprints for the upcoming Havana-3 deadline.

bash warning in Ceilometer test results

thomasm asked me about this warning when he runs the Ceilometer test suite:

WARNING:test command found but not installed in testenv
  cmd: /bin/bash
  env: /opt/stack/ceilometer/.tox/py27
Maybe forgot to specify a dependency?

dhellmann says:

you can ignore that warning

tox wants to help you make sure you have all of your test dependencies installed inside the virtualenv

but you don't do that with bash

tox is being told to run bash, but it found it outside of the virtualenv, so it's trying to warn you that you might be missing a dependency

you can safely ignore the warning for bash, since that's not a python app :-)

People fixing bugs I reported

• Previously, I reported the bug "test failures for alarm threshold evaluation due to undefined global name"

  https://bugs.launchpad.net/ceilometer/+bug/1211975

  flwang got this patch expedited and merged: https://review.openstack.org/#/c/41846/

  I confirmed that his patch worked and gave him a +1 in code review.

• Previously, I reported the bug "MongoDB PyMongo username/password warnings occur when running tests"

  https://bugs.launchpad.net/ceilometer/+bug/1210674

  sileht is working on a patch to fix this issue:

  https://review.openstack.org/#/c/41719/

  Yesterday, I cherry picked his patch and found there were still 3 warnings. He said that the 3 warnings should go away when the "Use new olso fixture in CM tests" patch https://review.openstack.org/#/c/41422/ is merged

  So I gave him a +1 code review.

Discussion with jpich

I asked jpich more questions about testing.

• I asked if OpenStack does validation/verification testing. She said:

  Not directly upstream, I think, except for developers casually checking that things work. Companies like Red Hat would do #3 internally (and contribute the test cases back upstream, as much as possible).

• I asked about how OpenStack does mocking.

  Most of OpenStack uses mox, and although there are talks of moving to mock (which I would really like, as the way it does mocking feels more intuitive to me) but that's such a huge effort it's unlikely to happen at the moment, when people would rather see new features.

• I asked what are some good examples of mocking in OpenStack unit tests?

  Pretty much every unit test I would reck on, particularly in the clients.

  Sometimes we mock "manually" by creating fake clients or classes, for the flexibility of having dummy clients we can reuse that behaves nearly like real clients (except for needing to make calls).

  Maybe poor Horizon has the most mocking examples. Since we talk to every single service out there, we need to mock nearly everything whenever we want to load a page

Group by blueprint

• group by blueprint on Launchpad: https://blueprints.launchpad.net/ceilometer/+spec/api-group-by
• group by blueprint discussion on the OpenStack wiki: https://wiki.openstack.org/wiki/Ceilometer/blueprints/api-group-by

Discussion with jd

• I was wondering if it matters what I use for the secret variable for processing the sample. In some test databases, I see

  msg = rpc.meter_message_from_counter(c, cfg.CONF.publisher_rpc.metering_secret, )
  

  In others,

  msg = rpc.meter_message_from_counter(c, secret='not-so-secret', )
  

  jd says that for the tests, it doesn't matter what value I set secret to.

jd's Patch Set 3

jd updated my patch. Here's what he did:

• Fixed a few tests

• Changed the group field name of the models.Statistics class to groupby and changed the result to a dict rather than a list

• Implemented the SQLAlchemy support and activated the tests only for that driver

  They all pass, except one, the one with groupby=['source']. The reason for the failure is because the implementation maps the groupby requested fields to the column table names in SQL, but this one isn't named source but 'sources'. This is a bug.

Next steps for blueprint

• Modify the prototype of all get_meter_statistics() functions to accept the groupby parameter, raising NotImplementedError in the first place.

• Add tests to check group by in combination with the period parameter.

  • group by single field with period
  • group by single metadata field with period
  • group by single field with query filter and period
  • group by single metadata field with query filter and period (this is the example in the wiki)

• Add tests to check for incorrect values like groupby=['user_id', 'bogus']

• Start implementing MongoDB driver

• Write patch to rename sources field to source in the SQL driver, so that the SQL driver tests pass