This week we began by providing updates on where we are at with our individual projects. We also need to find out exactly what format the folks over at Eucalyptus want our documentation to be in. Then we will need to convert our simple text format over to whatever they suggest.

We also discussed beginning a paper on an ethical analysis of Eucalyptus. This is something to work on and be due at the end of the semester. We will be writing about something we find to be negative about Eucalyptus or Cloud Computing in general. This can include aspects such as: security, reliability and privacy.

I’ve also just continued with documentation on the Eucalyptus Architecture Overview (Block Storage Controller).

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

Karl asked me to compile all of the FAIL Meters (Tom Calloway) and come up with one final review.  Here are the results with details elaborating each factor they accrued FAIL points for:

Size: +10pts

Eucalyptus received a total of 10 points of fail due to size and compression.  This suggests a great amount of obsolete code.  The first step would be to dedicate an individual to removing this obsolete code and standardizing the software.

Source Control: +5pts

Many people said the documentation for the source control was extensive, hard to follow, and  dependent on a programming background.  It is slightly more acceptable to require a background in programming when it comes to source control, but not to the point where even those with a background struggle to get through it.  Remember, the goal is to make this project as open-source as possible.  We want even those with no background able to contribute.  If the Wiki is so long that a new user is instantly turned away by the sheer size of the source control documentation, it probably needs to be edited.

Building From Source: +15pts

A few people said that it could be difficult to understand the documentation if you had little programming background.  So I tagged on 5 more points of fail.  This is probably the easiest part to fix.  Within a short time the documentation could be improved and use language that essentially anyone could understand.  This would also allow new users the ability to utilize Eucalyptus without requiring them to have a background in programming.

I also tagged on 10 points for containing hand-written scripts.  This isn’t a world ending add-on.  In fact, we might want to waive this, considering the type of project Eucalyptus is.  It’s a specialized architecture project, so you can expect some custom shell scripts to be included.

System Installs: +10pts

Many people tried to get Eucalyptus out of the 10 pts, explaining that it ‘recommends’ installing in ‘/opt’, but you can choose a different directory.  At the end of the day, it doesn’t matter.  It installs into a directory that it doesn’t/shouldn’t have too.

Releases: +5pts

I added a small amount of fail to releases because of the time frame of releases.  There isn’t any established consistent release date for new versions.  Releases come periodically, every 7-9 months or so.  Establishing a deadline and project goals would greatly increase Eucalyptus interest and drive.  People tend to procrastinate without deadlines.  Having a deadline with project goals gives the community something to look forward too, and the engineers something to work on.

History: +5pts

Eucalyptus started as a University project, and wasn’t open-source until some time after.  I gave them a reduced +5pts because they have earned it in regards to how open-sourced they are now.

Final: 50 Points of Fail “Babies cry when your code is downloaded”

I don’t think this is a bad place to be.  You can see a clear direction for Eucalyptus, and there is a lot of potential.  However, there are a lot of areas that can be improved.

The FAIL Meter assessment allowed me to take a look at the entire Eucalyptus project with a completely unbiased opinion.  Interestingly, the fail meter doesn’t dive deep into the source control.  Eucalyptus could use some improvements in the source code, particularly documentation and standardization.

The bigger problem lies within the management of the project.  Eucalyptus doesn’t follow any release deadlines.  Without release dates, software engineers don’t have a vested interest in the project.  They can get around to their assignment when they feel like it.  The community doesn’t have anything to look forward to and be excited about.  If you think about a successful open source project like Ubuntu, not only do they have planned release dates, but their releases are reflected in their version numbers.  There is always a lot of hype when a release is around the corner.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

At the end of the last class, we decided to use the built in issue tracker for github to track our progress and also to make sure no two people are working on the same project at the same time. This way, each person can choose which file or which directory they would like to work on and they can open a ticket or issue that corresponds with their project. Once an issue is opened, it is saved on github for the rest of the group to see so they can make a choice regarding what they want to work on. It prevents accidental duplication of work and it also lets the community know exactly what we are working on at that point in time.

As of this point, I have an open issue that corresponds to the eutester/eutester directory and I have added a milestone that lets everyone else know that I have finished the eulogger.py file. Each time I finish a piece, I can add a new milestone to record my progress. I know that Nate also has an issue open, and I believe that Stephen, Coady, and James were all opening issues as well. So by the end of the week, we should know exactly who is working on what part of the project and where they are with it. If not, I may have to open several issues and assign them to members of the group myself via github. However, either way, we will know more as the week goes on and the project should start getting closer to complete!

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

I just submitted my first patch of code! It only contained minor code changes including comments and moving code to a function instead of leaving it out in the open, however it seemed to help significantly. I used a short shell script written by Nate Doe to help me out in linking my local repository to the main github fork for our class. I simply followed the git commands and used the shell script to finalize the commit and push the changes. I asked my group to work on specific classes, so we should have more pushes this week. I also have some more ideas for changes to other classes, so I should have more this week as well. Looking forward to finishing our first directory!

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

This week, I was actually able to not only add some documentation to the eutester code, but I actually made some small code changes. There were a few existing comments in the code that basically said “This code block needs to be moved into a function at some point,” so I went ahead and created the function for it. I worked specifically the eulogger.py class and I added a bunch of comments explaining the code and I was able to actually get the code to compile cleanly after moving the code block into a function. 

I am looking forward to testing the code, but as of now, it is very exciting that I was able to modify and compile the code so far. There is still a lot of work to be done, but I feel confident that we will be able to commit a lot of useful documentation and minor code changes. Even though what we are doing is not very large or innovative, it is still useful to the Eucalyptus community and it feels good to know that we are helping out. I should be ready to commit a patch (or at least push some changes) within the next week. I would like to really finish up some more stuff before committing, however I think I am almost ready to go. I will do my best to have something up by the end of the day, but we’ll see how much gets done. 

The next step will be to finish up the rest of the eulogger directory. I will discuss this with my group and hopefully assign different classes to different people and get several classes committed this week!

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

This week we created an EtherPad to document and organize the mid-semester status of all our collective Eucalyptus documentation. Using the following EtherPad: http://typewith.me/p/Mid-semester_status, we were all able to contribute and describe what the status of our portion of the documentation is. We included the following information to describe our portion of the project and it’s status: Description, Who is Working on It, Current Status, What Has Been Done, What is In Process, What Still Needs to Be Done, What Resources Do We Need, and Other. This is going to allow us to keep track of what we’ve all done so far in regards to working with Eucalytpus as an FOSS thus far.

After meeting with my group to discuss and go over where we are all at with our individual parts of the project, I was able to continue with my documentation on Eucalyptus Block Storage and Amazon EBS Backed Images.

I updated our portion of the WiKi with my findings and research on Eucalyptus Block Storage Service (http://cs.worcester.edu/wiki/index.php?n=Main.ArchitectureOverview).

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