I just wanted to let everyone know of a free software cloud management framework I’ve been building. If you’ve read the CCIF mailing lists or my twitter, then you’re probably already aware of it. This project is called Annelidous (www.annelido.us). It enables the building of public and private cloud infrastructure services (IaaS), API agnostic frontends, and API proxies. It is licensed under the AGPLv3, more information regarding the AGPLv3 license can be found on the annelido.us website and at www.fsf.org.
So far, I’m running Annelido.us to run the services of GrokThis.net and VPS Village, but it has potential beyond simply hosting. Runnable code is now available for managing Xen clusters over SSH, and an initial frontend based on xen-shell has been completed. Some work has already begun on backend connectors to EC2 and Vertebra-xen. All of this code is available in a public git repository.
The design goals include the potential to build proxies between various IaaS APIs. As an example, a proxy could be built that allows a frontend with support for the OCCI API to communicate to a cloud which offers the EC2 API. This might also then include the ability to automatically and transparently allow OVF files to be used on EC2.
Frontend applications will be able to use this framework to access a variety of ‘Connectors’ through a common Perl API. In this sense, I intend for it to provide something analogous to what DBI provides for databases.
It should be noted that support for billing/accounting modules is being built in as well. So far, it integrates with Ubersmith, a billing manager oriented for web hosting operations.
I have very noble goals with this project, but as of yet, it has only scratched the service of its potential. There is currently an IRC channel on irc.freenode.org, #annelidous, and a public git repository. You can accept this as a call for both awareness and for assistance, so that we can have a free, open, and interoperable solution for building, connecting to, and supporting future IaaS solutions.
Richard Stallman has requested that I stop using the word “cloud”, saying that it is too nebulous a term. The following is based on the reply I gave him.
I’m not sure that it is feasible or advisable in either formal business context or documentation to completely eliminate the term cloud” at this time. This is why Larry Ellison has said that while he doesn’t believe in the cloud computing hype, that he will market products under this term. Yet, I think that there is a good sense in avoiding the word “cloud” when describing certain products and services when there are more precise terms that can be used. When it is used, it should be used in the correct and proper context, without ambiguity.
While I see how the word has been overused and abused, I’m not yet sold on eradicating it completely. I myself was very much against this term a year ago when I understood it less than I do now, and had publicly said that it was an “empty buzzword”. After I received a fury of emails and tweets regarding it, and after I spent more time to understand the movement, did I begin to feel that there might be some substance to the term. The problem is that it is very misunderstood.
I very much agree that “cloud” is a very vague and nebulous term, but this makes it little different from a similar word, “network”. Networking even has the OSI model, similar to how there is a stack being designed around “cloud”. I think a big difference here is that “network” now has a long history of use and is now well-understood. At the very least, nobody seems to be fighting the use of the term.
Network interface cards, network services, ethernet networks, wide-area-network, local-area-network. There are all terms that have grown around this one nebulous term. There are, however, terms that are very much removed from the OSI model, such as “Network Neighborhood”. It might be this latter sort that we’re seeing with the “cloud” buzzword. This might just require advocacy and education, and some agreement between vendors to assure that the term is not misused too frequently. The latter is something that the CCIF has attempted to do through one of its working groups, in order to define a “taxonomy”, an attempt that has, unfortunately, been largely inert.
By calling my IaaS software solution a “cloud management framework”, it was confusing as to if this was a solution for IaaS, PaaS, or even SaaS. It could have described any of these layers. This is why I’ve chosen to instead refer to it as a virtual-infrastructure management framework and/or a cloud infrastructure management framework. To draw a parallel to “network”, one could create a “network management utility” to manage servers, but this could also describe an SNMP browser, a firewall, a router, or even a pair of scissors. For this reason, those publishing a “network management utility” must take care to name and describe their solution in an unambitious fashion. Yet, we survive with this nebulous “network” term and we usually aren’t too confused by it.
Finally, Richard had indicated that we don’t need a term at all. My opinion is that the only reason that terms come into existence is from need, so “cloud” exists because there was sufficient reason to define a term. If this isn’t a good term one, an alternative one would still be needed. If the confusing, nebulous nature is the only objection to “cloud” then it should only be better defined, understood, and used in a more clear context.
I decided that one tweet would just do justice for this great event. I’ll start by saying that I honestly had a very good time. The people from Sun were all great, and I’m grateful that they hosted us.
The food and open bar were excellent, although it was a shame that the lobby was a bit too small for the group. Then again, there was a bigger than expected turnout, according to Jesse. This was my first unconference, so I had a lot of reservations about it, but I tried to participate as much as possible.
As for what was discussed and accomplished? I personally attended two unconferences, “Cloud API” and “Building Clouds”.
I ran, or attempted to run, the Cloud API discussion. We had a group of only about 15, while the discussion was mostly betweeen myself, R. Cohen, and Ian Murdock (yes, of Debian fame). They shared the belief that it was too early for an open API, while I advocated that it is needed as soon as possible. I’m sure that this disconnect came from the fact that they are developers, while I’m a hosting vendor. Of all possible parties, any delay on the availability of an open API affects me most seriously. I don’t believe we really accomplished anything at all, but it was a great introduction to the sort of work that we’d continue into the next day at CCIF, which I’ll blog about separately.
In the “Building Clouds” discussion, the discussion was a bit more diverse. There was another hosting provider represented, and we were able to share our experiences more than anyone else as few others had implemented anything close to a cloud, and of us all, we were the only ones that were serving the general public. I honestly didn’t gain a whole lot from this conversation as some of the big questions I have seem to have only been solved by a very small number of companies, none which were represented. The questions and concerns that people had in dealing with building clouds were issues that we’ve already solved for ourselves, but are general speedbumps that anyone will have to go thorugh. Some of the questions I personally had were at least touched on, but not entirely answered by David Bernstein at Cloud Expo, and I might look further at Cisco when we get to a point that we’re ready to solve those problems.
Finally, I had the chance to meet some great people from Sun and got to leech and share some great ideas. We’ll be experimenting with some of the things we’ve learned on some spare hardware and after making lots and lots of backups, we might try doing some cool new things on our OpenSolaris based SAN.
Overall, I’d say that CloudCamp really got me to connect a bit more with the users and to get an idea of what the users and developers are looking for in a service. This, along with discussions at CCIF have really helped me begin to identify some of these things that we’ll need to work on and solve, both as a community, and for my own business as well.
What is it?
I’ve hacked together something based on ReGrowl, which provides caching of Growl messages and a poller to retrieve those messages and distribute them to local Growl clients. The idea is that the server can exist on one network, the cache on another, and the poller on a third; or any combination thereof.
This is useful for sending Growl messages from internet servers to machines behind a NAT, without having to make modifications to one’s router. It is also useful for simple Growl message caching. When your desktop/laptop is shutdown, or off the network, messages will be queued until your return!
This requires memcacheq (which requires Berkeley DB4.7) and python-memcache.
Feedback
I love getting feedback from users, so if you find this useful, let me know! My e-mail is eric at windisch us, and I’ve enabled comments on this page, please feel free to leave a message.
Downloads
So, we haven’t yet unlocked the T-Mobile G1, but we have managed to obtain root on it.
There is a RIL API available, and we can access the RIL directly. Presumably, we might be able to directly access the RIL and do some hexediting, and that might be the only solution. I’m making a leap of faith here in saying that I don’t believe the kernel driver itself would be hardcoded to T-Mobile.
I’m quite sure that the radio interface is /dev/smd0, if anyone wants to play around with it directly.
For reference, here is information on how the iPhone is/was unlocked. Note that the “tty.baseband” there is “smd0″ on a G1. The programs they use won’t work, but the steps and requirements won’t be all that different, I suspect.
http://iphone.unlock.no/testpoint_unlock.htm
