Week 6:
During the meeting this week, all groups presented their work on Eucalyptus project. I participated on EuTester bug tracker, which we could not find any issues since the software is very new. However, there were 15 issues reported on GitHub, which 9 of them are closed. The open issues are as follows:
- Define licensing – Need to figure out what license we’re offering Eutester under. I presume GPLv3 to be compatible with the Eucalyptus product itself, but we need to be explicit. Also, need to make it clear that it is copyright Eucalyptus.
- Create a standard set of debug tools available when tests fail – When a eutester test fails, we need to provide a standard set of debugging tools back to the user. This debug info should include as much as is necessary to find the possible cause of the behavior. Currently, the Eutester class provides a very basic framework for this, but we would like to expand it. Some feature ideas for the debug tools set (not the final list): grep (already implemented), euca-describe-* (get a listing of all resources in the system), get_all_everything in boto, get logs, get topology, get distro, get build information, get environment (cpu, mem, etc), euca-describe-everything, get test script used, self replicating code, yum, and tar. In addition, graceful error messages (for instance, some tools may only work with root privs — so we need a nice “you don’t have the privs to do that” message for non-root users, instead of spewing gibberish.)So step 1 is presumably to figure out what the final list is.
We may need to break this into separate tickets if implementing some of these turn out to be less trivial than others.
- Create a standardized Eutester log/output format- We need to standardize the way we present info about a running test to a user – essentially, output formatting. Initial Thoughts
*date
*file
*function
* severity Eutester currently uses the python logging library (http://docs.python.org/library/logging.html) which seems to have everything we want, but just needs to be customized. Clarksb has offered to take this on — the first step will be figuring out the format we want (and then the next bit will be implementing it).
- Testing capability for Jenkins + EC2 Plugin Would like to look at test cases for Jenkins + EC2 plugin and whether this is possible to script. Jenkins has a CLI client but whether this works with EC2 Plugin is another thing: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI
- Goals, purpose, and guidelines for contribution. Need to produce better documentation: (1) Readme file should be bolsterd (2) Add more sample scripts (3) Ensure sane defaults (ie requests go to ECC by default)
Work cited
https://github.com/eucalyptus/eutester/issues
From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.