Category Archives: WSU CS

Meeting 5: EuTester and Eucalyptus Assessment

An useful tool that will help us alot while working with Eucalyptus cloud computing is EuTester. EuTester is a framework written in Python and is used as a test tool to test the Eucalyptus private cloud setup. It is designed to allow a user to quickly generate automated tests for testing a Eucalyptus or Amazon cloud. From what I found out, to be able to testing out EuTester, I need to have at least an instance running on the Eucalyptus cloud, but currently our cloud is still under the progress of setting up and I tried but couldn’t get into any other clouds. So right now, I haven’t had a chance to test out EuTester yet. Note that if you are running a Unix system, all the pre-requisites for EuTester are already installed.

Another subject we were dicussing in this meeting was how would we rate the Eucalyptus project? Is it a promising project? Or is it a failed one? So to find out, we would assess it based on a scale written by a guy name Tom Callaway. Based on him, a project can be rated based on 12 aspects: Size, Source Control, Building From Source, Bundling, Libraries, System Install, Code Oddities, Communication, Releases, History, Licensing, and Documentation. There were several questions under each aspects and FAIL points that go for each of those questions. If a question can be applied to the project, it will earn that much points, the more points the project is graded, it is destined to doom. Well anyway, it was tough to rate Eucalyptus because I couldn’t find much information on it to answer the questions, especially for Building From Source and System Install aspects. I know that Eucalyptus website provides a lot of documentation. So that was a good start. Looking through wiki, Eucalyptus forum, and many blogs, I would give Eucalyptus a score of 70 FAIL points. So it’s like right in the middle of the FAIL scale, not bad but not so good.

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

FAIL METER – Eucalyptus

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.

Week of Feb 27th 2012

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.

Post for 2/28

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.

Meeting 4: Getting to know Git

So in this meeting, the class and I will be getting to know more about Git, which is a version control system for a project, more can be read on its official website git-scm.com or github.com, a website devoted entirely to Git. So first off, I have to have Git on my system, which is an Ubuntu OS. 3 ways to get Git: downloading from its site, using the command: apt-get install git-core, or using the software center. There was also an exercise that we got to do to set up Git, edit personal info, and played with a repository. It was my first time experiencing Git so there was some confusions in me but it was a good start. At least I know some basics through the exercise. So I’m going to go through the tutorial on the Git website to get a better understanding of the system.

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

Fail Meter Analysis of Eucalyptus

Professor Wurst decided after viewing this article that we should gauge the project that we plan on spending an entire semester, I guess now is the best time do find out is after we’ve committed to the project.  Kind of thought it was a bit silly at first but the more I worked on the test the more I learned about Eucalyptus.  After all was said and done it turns out the project isn’t going to completely bomb, which wouldn’t have been the best for the class, or the project…

The tests are broken into several categories:

  • Size
  • Source Control
  • Building From Source
  • Bundling
  • System Install
  • Code Oddities
  • Communication
  • Releases
  • History
  • Licensing
  • Documentation

It’s about a 60 something questioner, each question assigns a “fail” value to it and tallies it up at the end.  Some of the questions were pretty silly like, “ Your website doesn’t have any documentation” (this isn’t a question, I know).

I learned a pretty good amount about Eucalyptus with this project, pretty much because 50% of what I was looking at had me scratching my head or asking “How would I even find that out”.  Got to poke around the source code online in git and on a website called fossies the link I gave is directly to the Eucalyptus section of it.  Also this is the my first “big project” of code that I’ve looked at and it feels pretty daunting to see so much code spread out in so many classes but, it’s also awesome to see it all working in unison.

 

 

For now my main goal is to continue to read wiki’s and try to play around with Euca2ools and be able to be much more fluent on the systems so I’m not like a lost puppy.

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

Sorry for the Absence

Unfortunately I haven’t posted in a pretty long time, and I’m sorry about that to those few who are following.

 

Recently my main focus was to pick a distribution of Linux I wanted to use.  I tried mint and cent and didn’t much care for either of them, to be frank.  I’ve been using Archlinux for one of my classes and love learning though that distro but it proved to be an extra level of difficulty I could do without in this class, pretty much I kept bothering Dave about this or that and felt back.  I ended up talking with some friends and they suggested Xubuntu which is a lightweight distro of Ubuntu.  Since I am running the OS in a virtual box the more lightweight the better.  I reinstalled Git and Euca2ools and have just been reading a wiki every now and then.  I am eager to really start the class once the cluster is all set up and I know how to use it properly.

 

I’ll be posting again tomorrow about our homework assignment once I finish it (aka start it)

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

CS 401 – Building a Small Cluster with Eucalyptus

I consider myself an amateur system administrator. I know my way around a Linux machine. I know how to use basic command line utilities. I know how to use Vim. I work on servers at my internship. I maintain about 4. Now, here I am in CS 401… with 8 machines that I need to not only install an OS on and configure, but make them talk to each other as a full Eucalyptus cluster. It’s taking far longer to set this up than expected, but I feel accomplished because it took a lot of work to get to where I am today.

Understanding Eucalyptus

I came into this project knowing literally nothing about cloud computing. But from reading the Eucalyptus documentation, I have a vague understanding of what the various components do.

The first component is the Cloud Controller (CLC). The CLC is the gateway for access to a cluster. It basically runs the show. Note that I said clusters, plural. The CLC make high-level decisions and talks to the cluster controllers. Next, is Walrus, a persistent storage system for the users virtual machine images. The data is organized into buckets (get it?). Walrus can be installed on the same server as the CLC. The Cluster Controller (CC) is in charge of managing several Node Controllers (NCs). The CC also handles access to the Storage Controller (SC) which interfaces with different storage methods. The NCs are servers that run a virtual machine hypervisor (such as KVM or Xen).  The hypervisor manages all the virtual machines (VMs) that are running on the server. Put it all together and you have yourself a cloud!

Preparing Servers

My class has 8 machines running CentOS 6.1. One server will be the CLC, running Walrus as well. One server will be the CC/SC. The remaining 6 will be our nodes. If combining tasks on the servers becomes a problem, it shouldn’t be too difficult to move them to other servers, the only downside being that we will have less NCs.

I was confused about which VM hypervisor was going to be installed on the machines. All of the Eucalyptus 2.0 guides were giving instructions to install Xen. However, when I tried to install the Xen packages, they were not found. After some googling, I learned that with CentOS 6, support for Xen was dropped in favor of KVM.

Compiling from Source

I grabbed the latest and greatest code from the Eucalyptus Launchpad page. I found 3 helpful documents that allowed me to successfully build Eucalyptus. one two three. I’ve been documenting the process as I go on the CS 401 Wiki. It took A LOT of reading and some help from the #eucalyptus IRC channel, but I did it! CS 401 is now in possession of some fresh 3.1 binaries.

Installing Eucalyptus

Now that I have Eucalyptus 3.1 built, I need to install it on all of our machines. I have been using rsync to copy the binaries to the other servers. The CLC, CC, SC,  Walrus, and NC require different Eucalyptus services to be running in order for them to function. As of this writing I am currently having some trouble initializing the databases on the NCs.

I’ve made more progress this past week than any other week so far. Hopefully we can have a functional system in a week’s time.

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

EUTester

This week we broke into two groups, the install group – which will focus on getting the Eucalyptus cluster up and running –  and the research group – which is looking into various aspects of EUTester and Eucalyptus. I opted for the research group about EUTester. EUTester is a python framework for testing a Eucalyptus cloud instance to make sure that it is working and was installed correctly. This will probably be a very important utility since there are so many people working on the setup of the cluster, and nobody has ever set one up before.

I don’t have much experience with python, so installing the EUTester was new for me. Although it was not hard to figure out, it was a learning experience. So far I have only found that in order for EUTester to work correctly that there needs to be a configuration file added on the Eucalyptus cluster. I found meeting notes from doing a google search that helped explain some of the aspects of EUTester. http://lists.eucalyptus.com/pipermail/community/2012-January/000210.html

My goal this week is to continue to do research on EUTester and figure out where it is supposed to be installed (either the cluster or on individual laptops). I am also hoping to work through some of the python source code of EUTester so I can figure out what exactly it is doing.

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

Exploring Eucalyptus

We are finally beginning to delve into the world of cloud computing. The cloud that is being built on campus is almost complete and the team working on the installation is doing a great job and putting forth  a lot of their personal time to finish setting it up. In the meantime we have been given research assignments to coincide with the Eucalyptus installation to learn more about the project itself. I personally have been researching the bug tracking system that they are using. Currently you can access the bug tracker right from the http://open.eucalyptus.com/ page located under the participate menu item.

Image

From here we are given links to different areas in the Eucalyptus project. You can go straight to the issue tracker and view the current support issues they are experiencing. There is also a link to the launchpad which hosts all of the open source code for Eucalyptus. The launchpad also has a link on the top to view current bugs and lists them by their priority.

I have only just begun researching this portion of the project and the rest of the class is also researching other components. We are doing this to familiarize ourself with the many various aspects of the project and it is helping us learn everything involved in a shorter amount of time. Hopefully by the time we have our next class the cluster will be up and running and we can really begin to learn how the project works and maybe even contribute to it.


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