This final week – before the last class – I have been working on my part of our groups presentation on GitHub/EUTester Documentation and the ethical analysis of the Eucalyptus project Dr. Wurst gave us. Our group has made significant progress in documenting EUTester, and the majority of the python scripts now have headers that document what that script does! Having to go through the code has been a good way to force me to learn python, which I have had on my to-do list for a while now, and has shown me the usefulness of the language.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

While sitting here waiting for my iOS app to compile, I decided I would get all of the changes people had been making to our repository for EUTester. When I went to run the shell script that I have been using to get and merge changes, it failed to pull from origin giving the error “Repository does not exist”. After reading the emails Dr.Wurst sent out today I realized that he had moved the fork over to CS-Worcester/eutester instead of kwurst/eutester. I thought I would post the way to fix this problem with pushing to the repository in case anyone else gets this issue.

1) Open a terminal window and navigate to the eutester folder.

2) vi .git/config

3) Press the i key (this is for insert if you’ve never used vi before)

4) Under [remote “origin”] there should be a url = SOME URL (most likely ssh://git@github.com/kwurst/eutester.git)

5) Chage the URL to ssh://git@github.com/CS-Worcester/eutester.git

6) Press ESC key (this is to get out of insert mode in vi)

7) Type : x (this saves and closes the file)

8) You should now be able to pull from and push to the origin again.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

I have pretty much finished documenting the scripts in the testcases directory for EUTester. My next directory that I decided to move to was the Eucaops directory. I was able to go through the scripts in the directory and comment what they do in the headers, but for some reason I now get an error when trying to push my changes to the repository. After some googling, I figured out that GitHub had suspended my SSH key because they believed there was some weird behavior tied to it. I then had to create a new SSH key and tie it to my GitHub account. As of this point, GitHub still does not allow me to push changes giving me the error “Permission Denied (Public Key)”.

The GitHub help website (http://help.github.com/ssh-issues/) suggests testing your connection with: $ ssh -T git@github.com (which does work for me). I am able to connect to GitHub and have it recognize me and my rsa key, but I still get the error when trying to push to our fork of eutester. I am going to continue to look into this issue over the weekend so that we can get the changes merged.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

Since Trevor wanted the shell script for pulling and merging the changes from Vic’s repo and our repo, it’s probably a good idea to post it online for others who want it. Make sure that you DO NOT add the shell script to the eutester directory (we don’t want it added to the codebase), but rather in a directory above it. Put the following code in SOMETHING.sh

cd eutester    //Change this to the location of the eutester directory relative to the script you create

echo
echo Getting changes from upstream…
git fetch upstream

echo Merging changes with master repo…
git merge upstream/master

echo
echo Get any changes from origin…
git fetch origin

echo Merging changes with master repo…
git merge origin/master

echo
echo DONE!
echo

———————————————————————————————————————–

To invoke the script, just type sh SOMETHING.sh and it will pull and merge any of the changes.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

I have been continuing working on documenting the eutester/testcases directory of EUTester. More people seemed to have jumped on the documentation train this class so that should help speed up the process. We decided that we are going to track what people are working on by using the issue tracker on GitHub (https://github.com/kwurst/eutester/issues). Each directory/file that a person is working on will be considered an issue assigned to whoever is working on it. Even though people should be pulling & merging the repository frequently, this will help us not duplicate any work and work efficiently. There is still a lot of code to document, but we are definitely making progress.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

This week I started the process of documenting EUTester’s code (specifically the eutester/testcases/ folder). This was a learning experience for me since I wasn’t always one hundred percent sure what some of the eucalyptus calls were. Before I started I pulled and merged all of the changes from both vic’s repository and our fork and was happy to see that some comments had been added already to the code which made it a little easier to understand. I plan to continue chugging through the code and documenting as much as I can for the rest of the week.

This was really my first time using git in a useful manner, so I finally got to see how helpful it could actually be. I also decided to write a shell script for pulling and merging all changes for me before I start documenting and before pushing changes back. This makes the process much more streamlined – narrowing down down the process to one command.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

This week a new project was created based on my previous post for documenting EUTester. I was finally able to get in touch with Vic Iglesias – who is the main contributor to EUTester. He was thrilled to hear that we were willing to help with documentation. He joked that documenting code wasn’t his strong suite. Thankfully Clark Mattew – another contributor – had already laid out a document on the GitHub project on how to document in code which Vic sent me to (https://github.com/eucalyptus/eutester/blob/master/eutester/euproperties.py). Vic told me that he would try to be available for the EUTester group if we needed any help with documenting or using the tool.

Since I will be away this weekend, I won’t be able to do any further digging in the code unfortunately, but hope to pick up the project next week. I am also going to look into forking the GitHub project for EUTester so that Vic can easily review and merge any of our changes. The only request that Vic had (which I posted on our EUTester wiki page) is that we make individual commits for each method that you are document so that it will be easier for him to go through. I know Matt said he would be interested in joining this project, so we will also have to figure out how we are going to break up the code.

On another note this is the first time that I have used IRC (outside of class) to communicate with people of the project. I have watched the channel before, but it was cool to jump in there and talk to people. The group was very helpful – especially when I tried to talk to Vic at 10:30AM EST, they pointed out he was on the west coast and wouldn’t be awake for a while most likely.

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

Since EU Tester is written almost completely in Python, I was tasked to learning more about the language for future script writing/modification. I came across a really good website that has lessons that goes through the basics of Python: http://www.sthurlow.com/python/. It was very helpful and I would definitely recommend it to others in the class that want to pick up the language. I haven’t done much with scripting languages in the past, so Python was a new world for me. However, I got through the lessons quickly and it was very easy to pick up.

After I got the hand of the basics of Python, I started looking into the EU Tester Python code. There were a lot of functions that I did not know what they did, but using the API Documentation on the EU Tester GitHub project (https://github.com/eucalyptus/eutester/wiki/API-Documentation) and the Python Docs (http://docs.python.org/library/index.html) I was able to get the general idea of what each script was doing. While going through this code, I did start documenting what each script does (although I probably should have posted it onto the CS-Dept Wiki). I plan on continuing to go through these Python scripts and try to document what each one does even more (which is now posted on the wiki ) http://cstest.worcester.edu/wiki/pmwiki.php?n=Main.EUTesterPythonScripts

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

This week our groups were supposed to continue working on our assignments. I am in the EUTester group, and I one of my tasks was to try and get a connection to a test instance of an image, however do to issues with my virtual machine, I didn’t get as much done as I had hopped to. I was able to compile the source code, but I didn’t get a connection to ECC to test anything yet.

This week now that I have all of the issues with my laptop straightened out, I hope to be able to actually get something working with this. I’m still not sure how useful an instance of an image on ECC will be, and I think that our cluster will be the best way to test it. From what I’ve read on our mailing list though, it seems like there have been issues on that front as well with KVM not supporting our setup. So hopefully this week brings more success than the past week for everyone!

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.

For this weeks assignment, we were tasked to take a look at Tom Callaway’s Fail Meter that he laid out in his article: Hoe to tell if a FLOSS project is doomed to FAIL (see link below). This essentially is a check list that goes over things from dependancies to revision control to source size. One thing I did learn more about in this process is about the installation process. Since I have been doing more research on Euca2ools lately I haven’t really looked into the installation of Eucalyptus. This assignment however forced me to look into the documentation more and find how it is installed – and where they recommend the installation.

After analyzing the Eucalyptus FOSS project, I found that there is room for improvement. Based on Tom Callaway’s system, the project received a score of “FAIL: Babies cry when your code is downloaded”. I think this may be a little extreme, as I would say that the project seems more like a rating of “FAIL: You’re probably doing okay, but you could be better.” I say this mainly because some of the points that I marked down were recommended, but NOT forced upon the users. For example “tries to install into /opt or /usr/” it is recommended to install in the /opt directory, but it allows you to choose another directory if you wish. The most points came from the dependencies being a separate download outside of the source. If they were to bundle them together it would drastically improve the score (since they already violate the over 100MB rule it shouldn’t be that big of an issue). Overall I would give them a letter grade of B – doing well but still room for improvement.

http://theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

From the blog nathandoe » WSU CS by nathandoe and used with permission of the author. All other rights reserved by the author.