The Perfect Time to Try Eucalyptus

Eucalyptus 4.0 is coming soon, and you can try it in beta, on a single system, right now.

To take your own AWS-compatible cloud-in-a-box for a spin, here’s what you do:

  1. Install CentOS 6.5 minimal on a box that supports virtualization. Give it a fixed IP address.
  2. Set aside a range of contiguous IP addresses to play with. 20 should be plenty.
  3. As root, run the following command:

bash <(curl -s

That’s it.

It’s still in beta, so if it breaks, you get to keep both pieces — but it’s pretty stable for me.

The installation script is based on Chef Solo. The goal is to provide a very simple installation experience that results in either a running cloud, or a very clear explanation of why you do not have a running cloud. Once CentOS minimal is installed, a typical install takes about 15 minutes. (NOTE: do *not* install the Desktop version; NetworkManager and PackageKit get in the way.)

If you have any problems getting your cloud-in-a-box up and running, don’t hesitate to reach out to me on Twitter (@gregdek) or on freenode (gregdek, #eucalyptus). At this stage, bad news is the best news, so if you have bugs, let’s see ’em.

I especially invite my friends who work for OpenStack vendors to see how the other half lives.  😉

The Perfect Time to Try Eucalyptus

Who cares about AWS compatibility?

Simon Wardley is never shy to share a provocative opinion. 🙂

A summary of his latest missive: OpenStack is already doomed because of their inability, or unwillingness, to produce AWS clones. There’s nothing new in Simon’s position there, but it’s his bluntest statement of opinion yet on OpenStack’s prospects.

I’m not going to presume to agree or disagree with Simon’s prediction — but in his blog post and the ensuing conversation, I saw a few opportunities to clarify how I think about Eucalyptus and AWS fidelity.

* * * * *

First, on proving AWS fidelity.

Obviously, at Eucalyptus we think deeply about the AWS fidelity problem, and how to approach it. Simon suggests one possible model:

So could CloudStack, Eucalyptus, Open Nebula and some of the OpenStack party create a rich set of AWS compatible environments — of course. But the problem becomes you have to define one thing as the ‘reference’ model. The only way around this that I know is for the groups to create a massive set of test scripts and provide some sort of AWS compatibility service and define that as the reference model and each show compatibility to it and it to AWS. It’s possible, I’ve hinted enough times that people could try that route but there’s no takers so far.

I can’t speak for the other projects, but we find that the best tests of AWS compatibility can be found in the AWS ecosystem itself — which is one of the key advantages of working in such an ecosystem. Chasing a full API is an exhausting process, and can be discouraging, but we’ve had good success by first ensuring compatibility with the most popular open source tools in the AWS world. By moving progressively through these tools, we will cover ever-expanding sections of the API, leaving the dustiest corners of the API for last (perhaps never even to be implemented; after all, an API is ultimately only as useful as the tools that exercise it.)

The Netflix OSS toolchain is a great example of this. The team at Netflix has taken quite a bit of heat for relying so heavily on the AWS family of services, but their decision to open source all of their tools has been a boon to us. They are smart users who exercise AWS at a scale that other users can scarcely imagine, so it’s a safe bet that they’re exercising many of the most interesting parts of the AWS API. We’ve learned much, and proved much, by following their trail.

Of course, we also have our own automated test suite for AWS/Eucalyptus fidelity; we call it Eutester. It’s designed, at least in part, to run identical test cases against both Eucalyptus and AWS, and anyone who wants to test the AWS fidelity of their own IaaS can pick up that code and run with it. That codebase will continue to grow as Eucalyptus grows. Patches welcome, as they say.

* * * * *

Second, on architecting for AWS fidelity.

It seems to be assumed — among some, anyway — that AWS API compatibility is something that can simply be dropped into OpenStack at any time. The trouble is, no one will know how true that is, or isn’t, until they actually do the work. Geoff Arnold’s comments hit the nail on the head:

Load balancing is a great example. For good or ill, Amazon’s Elastic Load Balancer is a cornerstone of web-tier cloud applications architecture. If the OpenStack community was serious about AWS compatibility, the LBaaS team would have established ELB compatibility as a fundamental requirement. It didn’t. On the contrary, much of the preliminary documentation focused on all of the cool features that LBaaS would support that were not available with ELB. By Grizzly, all that we had to show for our efforts was a proof of concept based on a single instance of haproxy. Elastic provisioning was officially out of scope for the core LBaaS effort.

Software design is about choices, and with every choice you make, there’s a chance that you’ve made some other choice impractical, or even impossible. We know that there are, at the very least, syntactic differences between OpenStack and AWS; it is also quite likely that there are deeper semantic mismatches.  It may be that the OpenStack community will be able to bridge both syntactic and semantic mismatches between OpenStack and AWS with ease — but given our experiences, it doesn’t seem likely. The devil is in the details, and one must care deeply about the details in order to conquer that devil.

* * * * *

Which brings me to the last point, which is caring about AWS fidelity.

As Thierry Carrez says,

EC2 API support has always been there in OpenStack. It just never found (yet) a set of contributors that cared enough to make it really shine. Canonical promised it (with AWSOME) then let it go. More recently Cloudscaling promised it, but I’ve seen nothing so far. The next in line might just deliver.

Maybe.  There is great power in being the one who “cares enough”. And Thierry’s response here begs the question: why doesn’t the OpenStack community care more about supporting the various AWS APIs?  (Since EC2 is just the tip of the iceberg.)

That’s a question for the OpenStack community to answer.  In the meantime, I can assure you that, at Eucalyptus, we care deeply about AWS compatibility — as do our users. We work towards that goal tirelessly, every day, and I think it’s safe to say it’s because of that passion that we have taken the lead. And it’s a lead that we have every intention of extending.

Anyway. See some of you at Netflix tonite.

Who cares about AWS compatibility?

New FastStart for Eucalyptus is officially live.

Today we officially launch the next generation of FastStart, the quick deployment solution for Eucalyptus.  We think it’s a pretty dramatic improvement to our previous version, and it’s certainly the easiest way to stand up your own AWS-compatible private cloud.

So go try it out.

And while I have you, I’d like to shout out to the guy who made most of this happen: a guy named Bill Teachenor.  When you use FastStart today and discover that it’s totally awesome, come by #eucalyptus and say thanks to bteachenor for all his hard work on the Silvereye project, the codebase upon which the new FastStart is based.  There were plenty of other folks who helped — but Bill was the one who took the ball.

Open source is powerful because you don’t need anyone’s permission to make it better.  You just need time, belief, determination, and a bit of skill in the right places.  Bill looked at FastStart with the eyes of an experienced sysadmin, picked out a whole bunch of places where we could do stuff better, and led the way.  When you write good code that does useful stuff, people will follow.  Rough consensus and working code: it’s what drives the open source world.

So here’s to Bill, and all the folks who say “I can make this better” and then commit code at 2am to prove it.

New FastStart for Eucalyptus is officially live.

Step two: put your cloud in that box!

(I’m sure you all know that step one is “cut a hole in the box”.)

We’ve been continually working to improve the install process of Eucalyptus over the past few months.   In particular, we’ve been working on a project that we call Silvereye.  Our most recent goal: make it trivial to install a fully-running Eucalyptus cloud on a single machine.

A cloud on one machine?  Why bother?  Well, lots of reasons, actually.  The biggest: the developer workstation.  If you’re hacking on Eucalyptus, it’s pretty awesome to have Eucalyptus on a single system that you tear down and rebuild in 15 minutes.

Anyway: mission accomplished.  Go to our Silvereye downloads directory and get the latest build (right now it’s silvereye_centos6_20121004.iso).  Burn it to DVD, boot your target system, and choose the “Cloud-in-a-box” option from the Centos-based installer.  Answer some simple questions.  Boom, in 15 minutes you’ve got a cloud-in-a-box!

(Note #1: a helpful README can be found in the Github repo for Silvereye:

(Note #2: in the cloud-in-a-box config, when you log in as root for the post-install config, it’ll say “hey, do you want to install the frontend now?”  Answer yes.  It automatically installs the node controller for you.)

(Note #3: Silvereye is not supported. At all. If you use it, there are ABSOLUTELY NO GUARANTEES that it won’t burn down your house, steal your pickup truck, or throw your mother into a wood-chipper.)

Silvereye is mostly the work of sysadmin-par-excellence Bill Teachenor, based on the original Faststart installer written by David Kavanagh — but various folks are now working on it; Andy Grimm, Graziano Obertelli, and Andrew Hamilton have all been pushing the cloud-in-a-box on various distros, and Scott Moser of Canonical did some great proof-of-concept work on the UEC code. So thanks to all of them, and everyone else who’s played with it.

Give it a spin; it really is dead-easy.  We still need to round off a few corners before we can call it the official installer of record, but we’re quite close now.

Want that AWS-compatible cloud on your laptop?  Of course you do.  Now go get it.

Step two: put your cloud in that box!

Bulletproofing the cloud

Here’s the thing about running your own cloud infrastructure: once you make the decision to rely on it, then it had better work.  The whole thing.  Every part of it.  Under heavy load.  All the time.

Obvious, right?  But it bears repeating.  When you decide to make the move to doing things The Cloud Way, you are placing a gigantic bet on your infrastructure layer — and that bet is placed not only on the Cloud As A Whole, but on every individual component that comprises that cloud.  In the open source world, these are frequently components that you didn’t write and do not control.  I can assure you that customers don’t care in the least.

At Eucalyptus, we have smart and demanding customers, with extremely high expectations.  They are not content with assurances that things will be production-ready at some magical release point in the future. They don’t care whether the bugs are in the cloud controller code, or the node controller code, or in libvirt, or in the kernel.  They are using Eucalyptus at extreme scale, right now, to solve extreme business problems, right now.  Which means that when their cloud breaks, they expect fixes right now — and if that means libvirt patches or kernel patches, that’s what it means.  That’s why they give us all that nice money.  That’s why customers pay us for free software.

Our customers try to squeeze every ounce of performance out of their machines; that’s part of the point of having a cloud, after all. And when the virtualization technologies we depend upon experience heavy load over a long period of time, we see some crazy things.  Like segfaults in libvirtd, for instance.  Or libvirt handlers that suddenly and inexplicably lose their mind.  Or other weird occurrences that might lead one to believe that libvirt isn’t quite as thread safe as advertised.  These failures may only occur at times of very high load, and they may not happen often — but they do happen.  And when they happen, we have to handle them.  The 3.1.2 release is the result of many hours of hard work by our engineers to find and fix these issues.

It’s a challenge and a privilege to serve customers like this.  At times it can put incredible stress on the entire organization — and it’s at precisely these times when we are at our very best.  Watching great engineers solve critical problems under pressure is a lot like watching great athletes at the end of a big game — and when they win, it’s just as exhilarating.  These engineers are at the heart of what we do. Compared to them, I’m just selling tickets and fetching Gatorade.

It’s not that hard to put together a bunch of components and call it a cloud.  But making a cloud bulletproof?  That’s hard.  And that, friends, is where we are the best in the world.

Bulletproofing the cloud

Next Euca hackfest: OpenShift integration

We’re going to be starting up our weekly IRC hackfests on #eucalyptus-devel next week.

There’s a lot of cool integration work of various kinds that we want to do with Eucalyptus, and it’s the kind of work that’s best done with many hands.  A lot of it is just “getting X to run on Eucalyptus,” and we want to fill in as many possible values of X as we can.  Thus, hackfests.

The goal is to have at least a couple of hours of non-interrupted hacking time every week, and we’re going to aim for end of week, either Thursday or Friday afternoon.  Figuring out timing is always an issue, so far now we’re just going to pick a time and see how it works out.  The first hackfest will be noon-2pm Pacific time on Thursday, August 2nd on #eucalyptus-devel.  This will overlap somewhat with the standing recipes meeting, but since we’ll likely be working on recipes much of the time, I think we can swing it.  We expect to have a few core people present at these hackfests every single week, but of course, the more the merrier.  It’s also perfectly fine for people to drop in and drop out as they may be available.

Our first target will be OpenShift Origin integration — so we’ll be all over the #openshift channel on freenode, and dragging as many of you as we can to #eucalyptus-devel in the process.  🙂

(update: what we’re working on is actually integration of “OpenShift Origin” — the bits that are used to make the OpenShift service, which is trademarked by Red Hat, etc., etc.  Must respect the brand. Post updated accordingly.)

Next Euca hackfest: OpenShift integration

EucaDay NYC: you are there!

On Wednesday April 25th, Eucalyptus will be hosting our first EucaDay. It’s a friendly little gathering of customers, partners, and community, and it’s free to attend. If you’re in the New York City area, you can register right now.

Of course, not everyone will be able to make it to New York City for this event. That’s ok, too — you can still attend and participate. For the sessions led by Marten Mickos (head honcho), Tim Cramer (lovable despot of engineering) and myself (community guy), we will be transcribing them live and in their entirety to IRC: #eucalyptus-meeting on freenode. In the morning session, Marten will go from 8am to 8:30am, and Tim will go from 8:30am to 9:30am. In the afternoon session, I will go from 3pm to 4:30pm, and then Marten will wrap up at 4:30pm. (All times in the Eastern US timezone.)

The community session will be particularly interesting, mostly because I’ll only be speaking for a small part of it. 🙂 We will be running a Eucalyptus mini-film-festival, where members of our community will link to short videos, and then take questions and answers on IRC afterwards. See what actual community members are doing, right now, to make Eucalyptus more useful.

The great thing about IRC is that you can fire up your client and lurk all day, if you like. Just read back for the interesting bits. 🙂 Logs will be available as well, as with all Eucalyptus meetings on IRC.

So. Join us on freenode, #eucalyptus-meeting, for the day on Wednesday. Lurk or jump in. Not being in NYC doesn’t mean you can’t join the fun.

EucaDay NYC: you are there!