Skip to content

Instantly share code, notes, and snippets.

@terriyu

terriyu/diary-12aug2013.md

Last active December 21, 2015 01:48
Show Gist options
  • Save terriyu/6229994 to your computer and use it in GitHub Desktop.
Save terriyu/6229994 to your computer and use it in GitHub Desktop.
Download ZIP
Journal for OpenStack Ceilometer work -- 12 Aug 2013
Raw
diary-12aug2013.md

12 Aug 2013

Questions

Beyond unit testing

I wanted to know more about other kinds of testing besides unit testing, for example, coverage testing. Unit testing is the lowest level type of test, but there are higher level tests like integration or validation/verification testing.

jd said:

Yes, OpenStack do have higher level tests, knows as "functional tests" with Tempest. Unfortunately, Ceilometer has no Tempest test written in it yet.

Sure, you can run coverage and get the results back by running: tox -e cover if I'm not mistaken.

jpich said that

  • OpenStack does integration testing with Tempest. Unit tests are meant to be fast, so they "mock" everything. Tempest test don't mock, but simulate a full OpenStack environment. Tempest is used in gate tests (that Jenkins runs), so theoretically if someone changed the API and broke another OpenStack component, the patch would not be allowed to merge. But this assumes that you have a Tempest test to check for this. (As jd noted, Ceilometer currently has no Tempest tests!)

  • Pointed me to the Tempest documentation: http://docs.openstack.org/developer/tempest/

  • Mentioned the Grenade project

    Recently the "Grenade" project was created to test upgrades from Grizzly to Havana. I think it's still quite a young project, but quite important to catch patches that could break the upgrade path (so we can either revert the patch, and make sure to document the new step that is required for upgrading.) More info: https://wiki.openstack.org/wiki/Grenade

OpenStack Python clients

I noticed that in the OpenStack GitHub repository, I see a lot of repos python-*client

There's:

  • python-keystoneclient
  • python-cinderclient
  • python-glanceclient
  • python-neutronclient
  • python-novaclient
  • python-ceilometerclient

I wanted to know more about what these do and why they are called "clients".

jd's answer:

Yes, though they do not only provide the command line tool, the command line tool is built upon a Python API that can be used in a Python program to access an OpenStack component.

That's called client because they connect to an OpenStack component which is a server. They communicate using the HTTP protocol.

jpich's answer:

Nova, Glance, Ceilometer are servers. They provide services (hah!) such as booting an instance, viewing the list of images or looking at meter types. By default the OpenStack servers provide REST APIs. By default you need to do quite tedious curl commands to communicate with the server

The python clients abstracts this (although they still use the REST APIs) so that you can communicate with the servers more simply. There's actually 2 parts to the clients (or well, that's how I think about it):

  1. The "library", that enables any program that imports e.g. novaclient to talk to Nova.
  1. The "command-line interface", that provides CLI commands which uses this library to talk to the server. (do_boot, do_list... which translate when using the command line as "nova boot ", "nova list").

She also said that the official OpenStack clients are in Python, but you could write your own client in a different language. (The APIs are REST APIs and REST is an HTTP protocol, so it doesn't matter if the server and client are in different languages.) For example, jd just wrote an OpenStack client in LISP. Also, the official Python clients usually lag behind the servers, so the client might not implement a feature that's in the server. In that case, you would have to update the client yourself.

Patches merged

The following patches I wrote to remove useless code were approved and merged:

Gordon Chung fixed the bug I reported "Cinder configuration (cinder.conf) is not automatically setup for Ceilometer during Devstack install"

Bugs, bugs, bugs

Devstack install problems

I had problems running the Ceilometer tests. The error messages suggested that my Devstack was out-of-date. So I destroyed my VM and started a new one. Then I proceeded to install a new Devstack.

However, Devstack failed to install when I ran the stack.sh script, due to this error:

IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/prettytable-0.7.2.egg-info/top_level.txt'

The full stack.sh log is here: https://gist.github.com/terriyu/6229153

From searching, I found these relevant bug reports:

And from the second bug report, I found the patch that fixes the problem:

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

This patch was merged while I was debugging, so I destroyed my VM and started another VM.

  1. I cloned the Devstack repo (with the newly merged patch).
  2. Installed the 10gen MongoDB package and removed the line for mongodb-server in files/apts/ceilometer-collector of the Devstack repo.
  3. Installed Devstack using stack.sh.

The prettytable error no longer occurred, but I got an error while running stack.sh saying that it couldn't connect to the MongoDB Ceilometer database.

JavaScript execution failed: Error: couldn't connect to server 127.0.0.1:27017 at src/mongo/shell/mongo.js:L112

Full stack.sh log: https://gist.github.com/terriyu/6229399

I followed the suggestion in this page: http://stackoverflow.com/questions/5726032/couldnt-connect-to-server-127-0-0-1-shell-mongo-js?rq=1

and ran the commands:

sudo rm /var/lib/mongodb/mongod.lock
sudo -u mongodb mongod -f /etc/mongodb.conf --repair

but this failed. The error still occurred. I decided to reboot my computer and that solved the problem.

Ceilometer test failures

Then I tried to run the Ceilometer test suite. When I run the Ceilometer unit tests, the tests for Nova notifier fail. The relevant traceback from running the Ceilometer unit tests:

Traceback (most recent call last): File "/opt/stack/ceilometer/.tox/py27/local/lib/python2.7/site-packages/mock.py", line 1201, in patched return func(*args, **keywargs) File "/opt/stack/ceilometer/nova_tests/test_notifier.py", line 153, in setUp notifier_api.add_driver(self) AttributeError: 'module' object has no attribute 'add_driver'

The full test output is here: https://gist.github.com/terriyu/6229473

The reason for the failures is that the function add_driver() no longer exists in nova/openstack/common/notifier/api.py

This commit to the Nova repository deleted add_driver(): https://github.com/openstack/nova/commit/7b92cc75bb940be2c6b0c4b75abc8358941a4a6d

I reported the bug here: https://bugs.launchpad.net/ceilometer/+bug/1211532

Group by blueprint

Useful references:

Submitted my first draft of the group by tests for the storage drivers: https://review.openstack.org/#/c/41597/

  • Jenkins gives me a weird message in the py27 tests results:

    2013-08-13 04:51:26.082 | Warning: you are leaving 124 commits behind, not connected to
2013-08-13 04:51:26.082 | any of your branches:
2013-08-13 04:51:26.083 |
2013-08-13 04:51:26.083 |   ab0ea27 Change the default sort direction of mongodb to ascending
2013-08-13 04:51:26.083 |   916e166 Change test_post_alarm case in test_alarm_scenarios
2013-08-13 04:51:26.084 |   0975ae3 Merge "Add support for API message localization"
2013-08-13 04:51:26.084 |   046eefb Merge "s/alarm/alarm_id/ in alarm notification"
2013-08-13 04:51:26.084 |  ... and 120 more.

    The full test results are here: http://logs.openstack.org/97/41597/1/check/gate-ceilometer-python27/5635209/console.html

  • I have no idea why but tox isn't running my new class StatisticsGroupByTest? The tests "pass" which is obviously wrong.

  • I was wondering where we should test the combination of doing a query with filters and a group by ? Would that be in the storage tests, API tests, or both? There is an example in the wiki which shows an HTTP request with both query filters and group by.

    The example is:

    /v2/meters/instance/statistics?
q[0].field=resource&
q[0].op=eq&
q[0].value=<my-resource-id>&
q[1].field=timestamp&
q[1].op=lt&
q[1].value=<now>&
q[2].field=timestamp&
q[2].op=gt&
q[2].value=<now - 6 hours>&
g[0]=metadata.flavor&
period=360

    Reference: https://wiki.openstack.org/wiki/Ceilometer/blueprints/api-group-by#Design

  • The models.Statistics iterator doesn't have an attribute for group names. The code for the models.Statistics class is here: https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/models.py#L209 So I invented a group attribute and used in the tests. I assume that if you do a method call like

    results = list(self.conn.get_meter_statistics(f, group=['user_id']))

    then the results will be arranged in an array, with one entry for each group (e.g. group-1, group-2, group-3) Also, each entry of the array has a group attribute group, so result[0].group should be group-1 or something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment