Of course, something would go wrong.  The fan in one of the machines has died.  We are also running into compatibility issues.  Dave fears the hardware in the current machines may not be supported.  Today, we discussed plausible alternative solutions.  Red hat has provided us with a small amount of money that we could use to buy a couple of new machines to get up and running.  Karl is also going to check with IT and see if they have any newer machines that we could use.

Meanwhile, Dave is going to see what he can do as far as software progress while we wait for a new hardware solution.  He will switch around one of the nodes and the CLC and try to continue so little time is lost.  I seem to be so busy with work at EMC, and numerous meetings that it has been very difficult to keep up with everything.  I have a conference at the NSF next week during Spring break too.  It feels like for every fire I put out, 3 more start.

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

This week I’ve been working on documentation for an overview on cloud computing in it’s general sense. I’ve been doing research and gathering information about cloud computing and it’s various aspects and traits. I was able to find lots of information about the pros and cons of cloud computing. I also found out a lot about how cloud computing has affecting the business world in positive ways and the manners in which it has provided cost savings. It has also provided a means for people to collaborate on projects without them needing to be in the same room or even the same country for that matter. I also found great information about the different styles and types of clouds. Clouds can be public, private or hybrid. They can also be serviced in different forms (i.e. IaaS, PaaS and SaaS). I’ve learned more than I knew before about cloud computing so it’s been an interesting week of research and documentation. I also read Chapters 1-3 on http://www.theopensourceway.org/book/The_Open_Source_Way and Chapter 6 in http://quaid.fedorapeople.org/TOS/Practical_Open_Source_Software_Exploration/html/ch-Debugging_the_Code.html. These readings were also very informative and I learned a lot from them. The information about Bug Trackers was most helpful to me. I was not completely familiar with that aspect of FOSS projects so I found that to be helpful in many ways.

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

This is a trial and error process, with a strong emphasis on error.  I’ve never used Python before, so I find myself jumping to Google search quite a bit.  Anyway, the first problem I encountered was starting a Python terminal, which turns out to be as easy as typing Python into an open terminal.  You’ll see ‘>>>’ to indicate Python is available.  The next problem was that I had not built Eutester correctly, turns out I needed to give root permission to do this.  Finally, I had a working version of Eutester and a Python terminal, but when I tried to run the command ‘from eucaops import Eucaops’ I got an error which seemed to indicate that Boto (the Python interface to EC2) is not working.

It seems I cannot create a connection to the Eucalyptus cloud.  I’ll edit this post after I figure out what’s happening.

Well, it seems there is a problem on the server end.  I talked with someone on #eucalyptus and created a forum post.  Hopefully this issue gets resolved quickly.

Images are again available, and I am resuming my quest to get Eutester to work for me.  My first roadblock this morning is that when trying to import eucaops I get an error telling me that a paticular class cannot be imported (BlockDeviceType).  A quick search of the file shows that this class was renamed to EBSBlockDeviceType. This error was caused by the simple fact that my version of Boto was out-of-date.  I downloaded and installed the latest version(Boto 2.2.2).

The next problem encountered has to do with credentials.  Essentially I need a credentials directory which contains a eucarc file from which key information can be extracted.  I resolved this be finding my eucarc file and copy pasting the path name.  I have been able to follow the the test listed here up until the ping test.  Despite several tries to authorize the group – default – I am unable to ping the instance.

This assignment has been frustrating, to say the least, but I feel I have a much better understanding of the process involved.  I will be updating the Wiki soon, so hopefully anyone else will be able to get eutester running in short order.

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

We are about halfway through the semester and it seems like things are moving kind of slowly. I have to admit that I did not get much done this week even though I set some fairly ambitious goals last week. I read up on some more of the Eucalyptus and eutester packages and I really don’t understand all of it. Also, Neo went down this week, leaving Morpheus as the head node in our cluster. This is a pretty decent set back for the class because we need to get euca2ools set up on either Neo or Morpheus (not entirely sure if it matters which one yet) in order to begin running instances of Eucalyptus and testing it using eutester. There is not much we can use eutester for in the meantime, though I and several of my group mates have been brushing up on our Python skills lately to make sure we understand the code thoroughly. This way we will be ready to start testing and writing code as soon as everything is up and running properly. This week I plan to do a little more research and keep an eye out for Neo so that I can get on and install euca2ools (if it is not already set up). Hopefully this week will be a little more productive on my end and a little less harmful for our server…

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

This week I read Chapter 5: Buiding the Code on http://teachingopensource.org/index.php?title=Building_the_Code&oldid=3622. I found this chapter to be very helpful and informative. It provided great tips and information regarding the best way to go about building the code for your FOSS. The information about installing and configuring the source code was especially helpful. I also read Chapter 4: Stuff Everyone Knows and Forgets Anyway in the book In The Open Source Way on http://www.theopensourceway.org/book/The_Open_Source_Way-Stuff_everyone_knows_and_forgets_anyway.html. This chapter also provided some great tips and information regarding simple things that one should be mindful of when they are working within a team on an FOSS. The biggest tip discussed was on open and thorough communication through direct means as well as mailing lists. I found this to be an important tip that made a lot of sense. I then assessed Eucalyptus against The Open Source Way’s checklist for determining whether a project is doomed to fail. The list of questions to determine is available at: http://theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL. I found it difficult to find some of the answers to some of the questions asked in the list. Therefore it was not easy to assess the project completely. I feel that it is difficult to predict whether the project is going to be a failure or not until we’ve completed it. This is because I personally have never worked on an FOSS of any kind and cloud computing is a completely new world to me. I am hopeful that it will be a learning experience and that I will gain a better knowledge and understanding, at the least, about working in a team on an FOSS.

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

We are moving forward with the Eucalyptus project. Our cluster is set, and the initial components of the Eucalyptus Cloud are in place. Our contribution to this project will be on improving a piece of test-software appropriately named Eutester. Written 100% in Python (note to self: learn Python), the program is intended to be run like a command-line script to test a running cloud.
Our project for the week included a couple articles to read, one on building executable code from the source code, and the other articles was “Stuff everyone knows and forgets anyway”, a basic reminder to keep everything out in the open, ect.

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 decided to apply what everyone has learned individually to the entire project and organize teams based on the existing knowledge of different groups. My group decided to investigates the test suite eutester and how to not only set it all up, but find out where to set it up on the server and how to apply it to the Eucalyptus software.

We each downloaded the eutester repository and built it locally and installed it. Then we began looking through the code to see if we could determine what was being tested. We understood the code pretty well, but we did not know how to use it properly since we could not figure out how to run Eucalyptus. We decided to set up a PiratePad for our group to keep track of our individual findings and apply them all to one group effort. We have a few ideas about how to get it all working because we learned how to download and run a Eucalyptus image, but we are not sure about where to go from there.

After logging in to the Neo machine and learning how the server is connected, I think it would be best to install Eucalyptus either on Morpheus, so that the Virtual Machines below it can all access it, or choose a Virtual Machine and work exclusively on that so we do not make any undesirable changes on the rest of the cluster. For testing purposes we probably want to use the latter, but eventually we may want to apply our system to the Morpheus node and let the VMs below handle parallel processing so that everything will be faster.

Basically, our goal for the week is to get Eucalyptus running on one of our nodes and then try to get the eutester code running as well. We want to see some output to make sure we are on the right track. Then we can document everything we’ve done so far and share it with the class/Eucalyptus community so that we can all get started on cranking out some test code. Next week, if all goes well and we have gotten the test code to run properly, we can start analyzing the output and look at some of the logged issues to start improving the existing code. These may be somewhat overly ambitious goals, but it is certainly worth a try to learn as much as we can and actually start contributing documentation and real code to this project.

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

Even though we did not have class last week due to the holiday, I still did a lot of reading up on the Eucalyptus software and the eutester code. I am very interested in looking into the testing package and hopefully contributing to it throughout the semester. I installed euca2ools and I think I learned how to run the software locally, though I am not sure how to use it yet.

Additionally, I got more comfortable with downloading the eutester repo and building/installing that code locally. I think that if I can learn to combine these tools and apply them to our server, we can begin testing and developing. I plan to spend this week and next week looking into how this works and hopefully I’ll be able to get some test code running by the end of the week.

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

Finally, we get to dive into some good stuff.  The Git assignment seemed pretty easy, but a lot of the commands were typos.  I guess that’s what you get for copy and pasting 😉.  I thought it was going to take me quite a bit of time to learn the ins and outs of Git, but I picked it up pretty quick.  Trevor Hodde also pointed me in the direction of GitK, which is a GUI representation of Git.  It gives a visual representation of the last time you pulled from the Git repo.  I would strongly suggest GitK to anyone who is knew to Git.  My group seems to be having some difficulty grasping Git, as two of them have yet to complete the Git assignment, but I am holding out hope.

My group also didn’t follow the details of the assignment, the purpose was to invoke a conflict when multiple people edit the same file.  Instead, they created a new file – no conflicts were made.  I finished the assignment for completeness, but I hope they understand the purpose of Git and version control.  The assignment actually had you set the user.name to “Your Name” and then color.ui, which is legal.  You can have the name variable contain multiple things.  Then, when you when to change it using git config –global user.name ‘James Forkey’ it threw an error saying multiple instances of the variable existed.  The fix I found was to edit the .gitconfig file itself and make it so there was only one name variable with the appropriate context.

I don’t really have much Git experience prior to this, but I know how it works and it’s critical role in the real world.  I can’t wait to really utilize Git to its fullest potential.  I am interested to see if there will be one person committing, or if everyone will be committing, potentially overwriting working code with either broken code, or less efficient code.  I guess this is something we should discuss in the near future.  Dave and Mike have done a great job with the infrastructure portion.  We are almost ready to get our hands dirty.  Exciting!

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