Wrapping Up Eutester Documentation

This week I've finished commenting on the webtestcase.py script and pushed the changes through. It was interesting running into my first conflict errors and having to pull changes from the origin master before being able to make any further pushes. So right now our group is almost done documenting the eucaweb directory with the init.py file being the only one left which I'll try to finish documenting next week. At this point we've done a good amount of work on eutester documentation in general, although it's looking like we won't be able to complete the project entirely with the semester coming to an end. I'm also disappointed I wasn't even able to develop any actual code to fix the issues on the Github issues tracker which I was planning on doing after the documentation project was finished. However, I feel good that we were able to help the creators of eucalyptus and I hope what we've done will assist anyone who works on the project in the future.

Documentation Continued

While working on eutester documentation last week I came across and watched this online Git tutorial video here (http://www.youtube.com/watch?v=ZDR433b0HJY). Scott Chacon (GitHub staff member) explains how the Git system works overall and how to use all the basic commands. I thought it was a good way to get an even better understanding of Git if you plan on using it in the future beyond this class. I also watched this video (http://www.youtube.com/watch?v=Z2ZL14WWEJI&feature=relmfu) where another Git expert showed some useful tips and tricks.

Last week I documented the euwebuser.py file in the eucaweb directory which is a simple script that sets up user accounts. But I wasn't able to push the changes right away because GitHub wasn't verifying my ssh key for some reason. I finally figured out the problem and pushed my modifications to the class's repository. Kind of cool to see Git working in real practice. I've also begun working on the webtestcase.py scprit and should have it documented later this week.

EuTester Issues Tracker/Documentation progress

This week was planning on continuing research on how to implement changes that will resolve the current issues listed on the EuTester GitHub. However I decided to switch my focus to helping with documentation for now since I had been going through the EuTester code anyway to gain a much better understanding of how everything works and what each directory actually does. Doing this has been a great way to get more experience using Git and seeing how useful it really is. Connecting with ssh interests me so I started looking though some files dealing with that (sshconnection.py , machine.py , ect...). I've started documenting already and should be ready to push my comments to our class's repository soon.

Python and EuTester Issue Tracker resolutions

I spent a lot of time last week learning more about the Python language because that's what EuTester is primarily written in. I went through a few online tutorials which really helped my gain a much better understanding of this scripting language. Knowing the basics of script writing in Python now, this week I was able to go through sections of the EuTester code that the EuTester Issues Tracker wants to modify (I updated what the current GitHub issues are on the wiki here: http://cs.worcester.edu/wiki/index.php?n=Main.EuTester). Those issues are:

Create a standard set of debug tools available when tests fail

A standard set of debugging tools should be provided to the user whenever an EuTester test fails. As much debug info as possible should be included to help figure out the cause of the behavior. Right now the EuTester class’s debug system is too basic and we want expand on it to make it more useful.

Create a standardized Eutester log/output format

The way information is displayed to a user after running tests should be more organized. Output formatting should be used to make the info more presentable. Some formatting options could be date/file/function/severity.

Testing capability for Jenkins + EC2 Plugin

We would like to test cases for Jenkins + EC2 Plugin and see if this type of script is possible. Now Jenkins has a CLI client but we’re not sure if this works with the EC2 Plugin.

Goals, purpose, and guidelines for contribution

Better overall documentation is needed. Some things that can be better organized: Readme file should be bolsterd/Add more sample scripts/Ensure sane defaults (ie requests go to ECC by default)

Define licensing

The need to figure out what license can be Eutester under. First proposition is from  Gregdek that GPLv3 to be compatible with the Eucalyptus product itself, but there  is the need to be more explicit. Also needs to be clear that it's copyright to Eucalyptus.

I already had Python downloaded on Ubuntu and just had to update paramiko and boto ect. I got an EuTester build working (downloaded and installed all the important EuTester tools as well) and was able to connect to a cloud which allowed me to start figuring ideas to modify the issues. The API Documentation for EuTester on GitHub was very useful to help me understand what most of the functions did. This part of researching was interesting because I learned a lot about how to use documentation to figure out what certain scripts actually do. Since I'm working on the Issues Tracker project which requires me to go though a lot of EuTester code, I plan on helping out with the EuTester Documentation project as well.

EuTester

Week 5 we broke into groups to work on different projects and my group worked on setting up and applying EuTester. The EuTester code is written in Python so before I could really get started I had get more familiar with the Python language. I went through some Python tutorials and one that really helped me a lot was this one: http://www.sthurlow.com/python/ . Once we all got comfortable with Python we tired to get Eucalyptus running and then get the EuTester code running.

Git

Week 4 was we mainly learned about Git, what it does and what it's used for. Git is basically a distributed version control system that already seems like it will be very useful tool for the remainder of this class. I haven't used Git version control much before this class but it was easy to pick up after working with it for awhile. The more I use it though, the more easier its becoming to remember the commands which obviously makes working with it quicker and smoother.

Selecting a Project to Participate in

This second class meeting was important because we had to choose what project we are going to work on for the rest of the semester. We had too choose from Libre Office, Sage, Irrlicht, Firefox, or Eucalyptus. I personally choose Firefox because it's one of my preferred browsers to use and I'm really interested in online programming, web design, and networking. We ending up going with Eucalyptus which I'm fine with because I would like to gain more experience with a Linux system. Working on this project should be interesting and I'm looking forward to getting started.

IRC Chat/Wiki Edit

In class our professor gave us a exercise in working with a person or a group of people that are in different locations. He introduced us to the IRC Chat program which we had to use to communicate with another person (we weren't allowed to talk to each other in person directly) and only use this tool to complete a task. The task was to edit our Wiki profile pages. I thought this exercise was interesting because it forces us to work in a way that we're not used to and that might be necessary when working on real open source projects. Overall the assignment went well and me and my partner were able to successfully edit each other profile pages while only making requests and giving information over IRC Chat.

First Post

This is the first post for my CS401 blog. I'm hoping to learn more about open sourcing and getting more experience working on FOSS projects. Also it would be nice if I could get more experience in some web programming areas such as internet security and networking.

One part of the online text that was interesting to me was the discussion about why traditional student projects are ineffective. It should be a good experience to work on a project that is much larger than anything I have done so far in school.