With just two classes left to the semester, I would rate our class as moderately sucsessful.  This in no way reflects the effort that went into setting up our cloud or creating our wiki entries.  I believe everyone who contributed did a tremendous job, especially on the server side of things.  Some things are just beyond our control, which does not make it any less frustrating.  At present it appears our last roadblock is getting the cloud to assign accessiable IPs that communicate between each other.

I reviewed our wiki, with an eye towards what is left to complete.  At present it seems all that is left is formatting (Architectue Overview needs color backgrounds added to code segments), and legacy posts added to a seperate page – I suggest this so that those that come after can have a better understanding of the process.

The project we undertook was ambitious – set up a functioning cloud with the latest release of the Eucalyptus and leverage that to write testing scripts which could be added to the KB.  But I do not feel we failed because we did not meet our goals.  Our class created an easy to follow wiki outlining the use of a Eucalyptus cloud and the tools needed to interact with it.  Most recently, work was done to make the scripts already available in the Eutester easier to read and follow.

I attended a EucaSchool planning meeting, where I suggested that future classes be captured on video.  This would allow those unable to attend to get the full impact of the class and should obviate the need to redo basic topics.  The idea was well received (it seems this had been suggested before, but no follow up was done).

Going forward, I would suggest that the Cloud be maintained as it could be a valuable resource for future CS students.  Either for the next CS-401 class or for other CS classes. 

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

This week we did not meet as a class, as we had the 16th off due to Patriot’s Day.

During this week I made a lot of progress with my documentation on Eucalyptus Machine Images (EMIs). I was able to research the topic using the following links as references for my own documentation:

1. http://www.eucalyptus.com/download/images

2. http://open.eucalyptus.com/wiki/EucalyptusImageManagement_v2.0

3. http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/Concepts_BootFromEBS.html

The Amazon AMI user guide helped to better understand Eucalyptus’ EMIs greatly.

I also began to think about what topic I’d like to tackle in regards to the ethical analysis of Eucalyptus/Cloud Computing.

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

Today I continued working on the eutester directory. I made some changes to the machine.py file and I’m looking at a few others at the moment. The good news is that we are continuing to make progress on the repository and hopefully it will be finished in another week or so. The bad news is that it’s been a week and only 3 issues are opened so far. I’m hoping everyone is at least looking at these files and trying to make changes, even if they are not very large changes. I should have another push or two by the end of the week, and I know Nate and Marcos have both had a few pushes already, so I’m hoping this will continue and we can finish this up fairly quickly. If everyone on the team does a few changes and commits them, we should be able to get everything done in a week. However, if things continue the way they are, and we average only 4 pushes per week, we may not finish the project entirely. 

I am ambitious about getting it finished, so I think that at the very least, it should be more than halfway done by the end of the week, leaving very little left for our final week of classes. If I finish my directory, and both Nate and Marcos finish theirs, we should be down to about 3 directories I believe, and there are at least 4 more people in the group, so the work should not be difficult to finish. I’ll keep working on my stuff this week, and hopefully I’ll have enough done to move on to another directory, or at least help some other people finish up theirs. I’ll send out an email about finishing this stuff up to my group this week to make sure everyone is on board. Overall, I think we are in decent shape and we should be able to finish everything we set out to do before the end of the semester. 

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

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.