Monthly Archives: March 2012

Version Control

This week I did a lot of reading on traditional version control systems (VCS) versus distributed version control systems (DVCS). Both sides of the aisle had good arguments for and against one another, but in my humble opinion DVCS is the way to go. It seems to me that the benefits of having a distributed code base outweigh the negatives of potential security issues. As long as everyone on the project is a semi-competent computer user there should be no problems with security.

I did, however, recently discover that not only was there a hack exploited against GitHub; the guys over at GitHub seem to have dismissed it completely without trying to patch the hole. My understanding is that the exploit uses Rails and requires the code base to be locked in order to work. Still, it is something that merits a patch.

I apologize for the scattered nature of this post and the shortness as well, I’ve been heavily medicated the last two days after a medical procedure. My next post will have more substantial content and coherent flow, I promise.

From the blog The Mind of Mattamizer » WSU CS by mattamizer and used with permission of the author. All other rights reserved by the author.

Week 5:

Week 5:

During the meeting in this week, we went through Eucalyptus tools.  In addition, most students volunteered on various tasks to get the contribution towards Eucalyptus project started. I volunteered on finding the bug tracker on EuTester, and check issues if there are any. After following the EuTester code, there were no any bugs as the code has been there for less than two months. Furthermore, I spent most of my week going through several Python programming books in order to understand the syntax and fundamentals of Python programming since the Eucalyptus project is in Python.

In addition, I read chapter 5, which covered “Building the Code”. This chapter brings about the general understanding of code building and its processes such as compiling the code, linking object files and libraries, determining build order and dependences, testing the build results, and packaging and/or deploying. All these process are quite effective as we eye on contributing toward Eucalyptus project. Nonetheless, I found determining build order and dependences mostly important especially on OSS and particular Eucalyptus project. Finally, this chapter overlay other great topics such Building Freeciv: Watching GNU Autotool at work, which mainly focuses on Linux or UNIX systems. I believe this is core to any project that is involves with GIT.

As the week went along, I had time to go over Chapter 4, which covers “Stuff everyone knows and forgets anyway.” After reading this chapter it was quite an experience, as I went through the covered topics such as Embrace failure, Communities require care and feeding to get started, And communities need to be left to grow and evolve, Remember what you learned in Kindergarten, Take extra extra extra care to have all discussions in the open, Take even more care to do all design and decisions in the open, Use version control for your content as well as code – everyone watches the changes, Choose open tools that can be extended, Focus on healthy and open community interaction, Seek consensus – use voting as a last resort, Reassign your benevolent dictators while evolving toward a consensus-based democracy, Do not forget to release early and release often, Do not forget to release early and release often, and finally Evolve with the growth of your audience and contributors. All these topics cover what each and everyone willing to contribute to OSS needs to know. Here is the link to this chapter for anyone with interest on learning these great topics regarding OSS Chapter 4.

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

CS401

This week we each went over what we learned about our respective parts in the Eucalyptus project. The server isn’t up and running yet but it sounds like it getting close. I have looked at the eutester software and installed it. There really isn’t much, if any, documentation on how to run and use the software on the eucalyptus website that i can find. The most information i found was in the README file that explains some of the uses and tests that you can run with the software. This week I’m going to try to figure out as much as i can about Eutester and hopefully we can start up a ssh connection with the Eucalyptus server so we can see how to run the eutester software. We don’t expect the Eucalyptus server to pass the tests (it’s not properly configured and running yet) we just want to learn how to use the software for when it is.

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

CS401

Last week we watched a video explaining some of the uses and commands of version control software. We used Git. It was pretty informative and we learned how to add a file, modify a file, and update your version of the software. We are also in the process of having groups work on different aspects of the eucalyptus project. I chose to be a part of the Eutester group and try to learn more about how to install and build the tester.

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

Making Progress

Personally, this was a slow week for myself. In class we discussed all of the topics for eucalyptus that we needed to get people working on. We arranged the topics, and with the help of etherpad, had people “sign up” for whatever area of eucalyptus they wanted to work on. I chose to be a part of the eucalyptus install team with Dave and Mike. The  networking aspect of things tends to interest me a great deal so I wish to work on that skill as much as I can.

I communicated a little bit with Dave throughout the week, and according to the massive amount of documentation he wrote up, it seems like he is making a lot of progress. As far as my end on the install however, I wasn’t able to get much work done this week. I did take a more in depth look at the user and administrator documentation on the eucalyptus website so I would have a better idea as to what was ahead of us. This coming week I plan on getting a lot more work done on the installs, namely getting some of the node controllers working. We are aiming to have this thing up and running as soon as possible!

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

Class Week 4

In this weeks class we focused on the different components that have to do with Eucalyptus. The class was divided into different teams that each have to do further exploring of the the different aspects of Eucalyptus and give an overview to the classroom about the overall project. The different parts that had to be researched include but are not limited to: the install, the testing, Euca2ools documentation, what Eutester does, what Eutester tests, where to install it, etc. These are just some of the things that we are working on this week and delivering our findings in the next class.

From the blog jgaval by jgaval1 and used with permission of the author. All other rights reserved by the author.

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.

CS401 FLOSS Doomed to fail test

Personally, I think that the test we used ( http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html ) is pretty silly. The criteria range from mundane to inane, and seem to automatically discount any project that might happen to be windows only (Say, perhaps an open source C#.NET wrapper for DirectX? http://slimdx.org ). I think there is some good information, but other parts of it are strange (Being vaporware means your project is doomed to failure? Who would have guessed?)

In any case, testing eucalyptus with this doesn’t really tell you anything about the project because it’s a long established project.

This week we also split into new groups and started working on seperate projects. I’ll be working on adding documentation to provide a more in depth overview of the eucalyptus architecture.

From the blog blabbecs401 » CS401 by blabbecs401 and used with permission of the author. All other rights reserved by the author.

How to tell if a FLOSS project is doomed to FAIL – Eucalyptus

Below is my analysis of the Eucalyptus project, based on the criteria described in
http://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL .

FAIL METER TOTAL
30
Although my rating technically puts the project into the “Babies cry when your code is downloaded” category, this is certainly a viable project. The fact that it is already a successful commercial enterprise makes this obvious. The tipping point is probably the size of the code, which is barley over the point criteria.
The areas where the project can use significant improvement are in the documentation. The existing documentation assumes a good deal of prior knowledge in Unix-based operating systems and version control systems (which is probably where we should focus our documentation efforts). This puts the software out of reach of the laymen user.
I’m sure this is why we were asked to help in the area of install documentation.

From the blog danspc.net Blog » wsucs by danspc.net Blog » wsucs and used with permission of the author. All other rights reserved by the author.