Final weeks,

During the final weeks, I worked on trying to resolve the open issues on Eutester. However, I did not really finish; still look forward even after the semester is over to contribute to eucalyptus. The currently  open issues are as follows:

• issue #2: Goals, purpose, and guidelines for contribution

• issue #10: Create a standard set of debug tools available when tests failissue #12: Define licensing
• issue #22: Need to investigate a tool that represents test results visually             

• issue #24: Restructure Eucaops into multiple modules

• issue #25: Need way for machine access when keys have been previously synced

• issue #28: Feature Request: Allow for NC to be an optional value in config_file

• issue #29: About this issue I suggest for everybody to ignore it because it is mistake
• issue #32: Added Changes Requested from Code Review Session in eutester meeting

• issue #33: run_instance should still provide a euinstance regardless of reachability

• issue #34: Move logging functionality from eutester.py to the machine class

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

During class meeting on this week, every group discussed their progress. As far as that go, my group still had difficulties running Eutester on their laptops. Thus, all we did was discussing the current issues and how we can fix them. During the week, I went through most of the code on Eutester as I was planning on working with the documentation team. However, every case was already assigned to the team members.

While the week went a long, I looked at the all ways that issue #23 ‘Create a Test Directory Wiki ‘ could be resolved. In according to the issue description the directory should be the start of what will be the directory for all tests and suites that wants to bundle with eutester itself. Moving forward any testcase that gets submitted into Eutester should be accompanied with a Wiki article that defines what the test does and why it exists. When the testcase and wiki article are accepted into the codebase they will be added to the Test Directory with a link and quick summary of the test.

I was quite lost on where to begin, but as of the 12^th week, I will contact Vic to walk me through in order to fix this issue. In addition, I will begin working on the wiki article for the testcases.

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

The following are the closed issues on Eutester:

• issue #1:  eutester should allow the opening of multiple ssh connections
• issue #3:  inclusion of test to reproduce https://bugs.launchpad.net/eucalyptus/+bug/737335
• issue #4:  Goals, purpose, and guidelines for contribution
• issue #5:  Testing capability for Jenkins + EC2 Plugin
• issue #6:  create_ssh does not pass correct key file name argument
• issue #7:  get_emi() in eucaops selects de-registered image
• issue #8:  README.md
• issue #9:  Create a standardized Eutester log/output format
• issue #11: connect to walrus should use s3_url
• issue #13: Now using Euinstance in Eucaops
• issue #14: Continuing integration of euinstance, removed some debug information
• issue #15: Continue implementation of euservice class and machine class
• issue #19: Added fix for eutester to work with Dynamic DNS-enabled Eucalyptus 2.0 Clouds
• issue #20: Fixed initial pull request
• issue #21: Added fix to handle Dynamic DNS-enabled Eucalyptus 2.0 Clouds
• issue #26: Allow credpath option with config_file option when instantiating Eucaops

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

Most of this week I went through Eutester code.  As, I wanted to join the documentation team to fasten the documentation process. All documentations tasks are assigned to the documentation team members. I still believe a well state of understanding the Eutester code will enable us to address the current issues in the right manner. I look forward on addressing the current issues and resolve them.  The current Issues are as follows:

• Need way for machine access when keys have been previously synced:- Currently we rely on the password to be passed in to Eucaops or Eutester in order to determine whether we will be needing to connect to machines (ie create machine objects). There should be a way to say that you want connections to machines without passing in a password.
• Restructure Eucaops into multiple modules:- Eucaops has grown a little too large for my liking and I’d like to split it out in chunks as follows: (1) EC2ops (2) S3ops (3) IAMops. We would then have a Cloudops class that would inherit from all of these 3 classes. The current Eucaops would then inherit from Cloudops and include anything that is necessary to use Euca (for example modifying properties) that does not apply to AWS.
• Create a Test Directory Wiki:- This directory should be the start of what will be the directory for all tests and suites that we want to bundle with eutester itself. Moving forward any testcase that gets submitted into Eutester should be accompanied with a Wiki article that defines what the test does and why it exists. When the testcase and wiki article are accepted into the codebase they will be added to the Test Directory with a link and quick summary of the test.
• Need to investigate a tool that represents test results visually:- Build a TestRunner similar to:  click here
• 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’s 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’d like to expand it.
• Create Goals, purpose, and guidelines for contribution:-  (1)Readme file should be bolsterd (2) Add more sample scripts (3) Ensure sane defaults (ie requests go to ECC by default)

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

During these two weeks in class meetings, we discussed the up to date progress towards our contribution towards Eucalyptus. All groups reported their progress on what they are working on ranging from documenting utester to documenting Eucalyptus Architecture Overview. In addition, the group working on setting up our cloud reported on their progress. My group was working on tracking the issues available on Eutester, and the ways we can apply changes in order to fix them.

Nonetheless, during these two weeks I worked on improving my knowledge of python. I found a very good tutorial online, which is very thorough (http://docs.python.org/tutorial/).  Further, I spent a lot of time going through the entire code on Eutester to see how the issues arises could be fixed. While going through the code, I found it very complex to understand the code since the documentation on the code is very poor; I look forward on joining the documentation team on the 10^th week to improve better understanding of the code. Good documentation will boost better understanding of the code in the future for other programmers willing to contribute and add more futures to Eutester.

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

During the meeting this week, we had a guest who is very familiar with Eucalyptus and Open Source Software in general, Mel Chua. She discussed various topics about effective contribution towards Eucalyptus. Since, I am working on trucking and reporting the issue/bugs and find out how they can be fixed. The most important topic in my point of view was regarding ways to begin fixing the currents issues/bugs on Eucalyptus Eutester. EuTester is a framework in Python, used as a test tool to test the Eucalyptus private cloud setup. Furthermore, it allows the users to generate automated tests for testing Eucalyptus or Amazon cloud fast.

Nonetheless, during the week I spent most of my time reviewing the Eutester code. However, I could not run the code. The current issues did not seem as that of a big deal if you are able to run the code after testing. Most of the week, I was researching on how to implement changes that will oversee the current issues.

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

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.

Week 5:

During the meeting in this week, we went through Eucalyptus tools.  In addition, most students volunteered on various tasks to get the contribution towards Eucalyptus project started. I volunteered on finding the bug tracker on EuTester, and check issues if there are any. After following the EuTester code, there were no any bugs as the code has been there for less than two months. Furthermore, I spent most of my week going through several Python programming books in order to understand the syntax and fundamentals of Python programming since the Eucalyptus project is in Python.

In addition, I read chapter 5, which covered “Building the Code”. This chapter brings about the general understanding of code building and its processes such as compiling the code, linking object files and libraries, determining build order and dependences, testing the build results, and packaging and/or deploying. All these process are quite effective as we eye on contributing toward Eucalyptus project. Nonetheless, I found determining build order and dependences mostly important especially on OSS and particular Eucalyptus project. Finally, this chapter overlay other great topics such Building Freeciv: Watching GNU Autotool at work, which mainly focuses on Linux or UNIX systems. I believe this is core to any project that is involves with GIT.

As the week went along, I had time to go over Chapter 4, which covers “Stuff everyone knows and forgets anyway.” After reading this chapter it was quite an experience, as I went through the covered topics such as Embrace failure, Communities require care and feeding to get started, And communities need to be left to grow and evolve, Remember what you learned in Kindergarten, Take extra extra extra care to have all discussions in the open, Take even more care to do all design and decisions in the open, Use version control for your content as well as code – everyone watches the changes, Choose open tools that can be extended, Focus on healthy and open community interaction, Seek consensus – use voting as a last resort, Reassign your benevolent dictators while evolving toward a consensus-based democracy, Do not forget to release early and release often, Do not forget to release early and release often, and finally Evolve with the growth of your audience and contributors. All these topics cover what each and everyone willing to contribute to OSS needs to know. Here is the link to this chapter for anyone with interest on learning these great topics regarding OSS Chapter 4.

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

During the fourth meeting, professor Wurst began with a brief introduction on GIT, which is a core essential tool in OSS. He played a video that demonstrated how to install GIT to Linux/Unix system, and how to use it.  GIT was designed and developed by Linus Trovalds, it was for Linux Kernel development. Its directory is a full-fledge respiratory with complete history and full revision tracking capabilities, which is independent on network access, in other words central server.

In addition, we had an assignment, which covered the basics of GIT. The assignment included GIT installation basics, and its configurations. This worked quite well despite a few problems with configuration; worked after a few trials. I look forward on working with GIT, as it is mostly used in Open Source Software contribution.

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.

The third meeting was crucial to this semester; we had to determine which FOSS project to contribute. The projects we had to determine from are as follows: Eucalyptus, Firefox, Irrlicht, Sage, VLC, and Libre Office. All of these projects are every interesting, and each has its own uniqueness. Thus, everyone had a different opinion on each project and we had to vote which project to work on. After the vote, the results varied in big margins. Eucalyptus and Firefox were the top projects, followed by Irrlicht, sage, Libre Office, and finally VLC. Between Eucalyptus and Firefox, Eucalyptus received the most votes. Accordingly, this semester would be a learning experience for everyone as we take on Eucalyptus project.

Eucalyptus is a cloud-computing provider. It was started as a research project in the University of California, Santa Barbara. For more information about Eucalyptus, you can visit the following link: http://www.eucalyptus.com/about .

Now that the project is determined, task is to learn the design process behind it and learn how to contribute to the maximum as time allows us. I really look forward on making great contribution to this project, while enhancing my software development contribution towards FOSS oriented projects.

From the blog Dnjoroge by Dnjoroge and used with permission of the author. All other rights reserved by the author.