Planet Eucalyptus

Eucalyptus 3 includes, as one of its new features, the option of enabling "High Availability" or "HA" (pronounced as the two letters and not as the first part of a chuckle). This functionality was overwhelmingly the most frequently requested improvement over Eucalyptus 2 by the community and, at the same time, the one over which the most confusion seems to persist. I'll try and shed some light on the "what," "why," and "how" of HA in Eucalyptus.

What: Automatic Failover and Recovery of Eucalyptus Services

Eucalyptus consists of a number of "always-on" interacting web services. In an HA configuration, each service can be configured with a running-but-inactive spare. If and when an active component fails or becomes disconnected from the other Eucalyptus services, the system will enable the spare on the fly and keep running.

read more

apt-get install screen

root@host # screen -L -S learningsession
root@host # Ctrl+a :multiuser on
root@host # Ctrl+a :acladd UserA
root@host # Ctrl+a :aclchg UserA -w "#"

UserA@host # screen -x root/learningsession

Must run suid root for multiuser support.

root@host # chmod u+s /usr/bin/screen

UserA:x:1000:1000:Test User,,,:/home/UserA:/bin/bash

~ $ cat .profile 
# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

screen -x root/learningsession
exit

root: ~ $ cat .screenrc 
multiuser on
acladd UserA
aclchg UserA -w "#

LSCRN=($(screen -list | grep learningsession | awk -F"." '{print $2}'))
if [[ LSCRN == "learningsession" ]]; then
     screen -x $LRNSCRN;
else
     screen -L -c ~/.screenrc -S learningsession
fi

Here is a summary of my tweets about the world and our planet from the previous months.

This is my previous tweet summary for Fall 2011. And, of course, feel free to follow my tweets in real time at http://twitter.com/#!/martenmickos

March

James Cameron completes 11km Mariana trench dive http://on.natgeo.com/GNSXlA

James Cameron begins descent to ocean's deepest point http://bit.ly/GQn516 - impressive stuff!

RT @RomanStanek Prague's Franz Kafka International Named World's Most Alienating Airport http://onion.com/dhkrSw

Bilingual makes you smarter. NYT http://t.co/3IqPauWw

Interesting reading: Index of Silicon Valley 2012 http://siliconvalleycf.org - half of the ppl speak other than English at home

RT @aneelb: Very cool report.

read more

Here is a summary of my tweets about interviews with and writings by me, quotes, and books I've read from the previous months.

This is my previous tweet summary for Fall 2011.

read more

Navigation by Cloud IT Roles

Information customized on a per-role basis

• Cloud Administrators will find install and maintenance guides. In case they get into issues they can search our knowledge base for the specific error code, or engage other administrators to discuss about the different installation options or what is the best hypervisor for their situation; 
•  Developers can quickly reach the latest source code, looks at currently worked on issues, and start talking about the latest patch they have been working on. Detailed informations on Eucalyptus internal structure and API supported are also the bread and butter for Developers;
• Application Architects will find everything about our starter images, from what's inside and why, to how to recreate and modify them. They would want to use and modify the instances recipes and share their latest scripts to recreate their production environment. 

Find how to participate independently from your role

Here is a summary of my tweets about leadership and entrepreneurship from the previous months.

This is my previous tweet summary for Fall 2011. And, of course, feel free to follow my tweets in real time at http://twitter.com/#!/martenmickos

April

Keep your own scorecard. @CharlotteBeers on self-assessment, leadership, recruiting http://nyti.ms/H5efKb - brilliant Q+A from start to end

March

Should attractive women not include a photo with a job application?

read more

Here is a summary of my tweets about open source from the previous months.

This is my previous tweet summary for Fall 2011. And, of course, feel free to follow my tweets in real time at http://twitter.com/#!/martenmickos

April

"Scarcity is the enemy of serendipity" - thoughtful piece on Burning Man dilemmas by @jessbruder http://nyti.ms/HJjLBb via @brown2020

March

Awesome dinner w/ former MySQL execs http://lockerz.com/s/196629110

Congrats Jim & team! Red Hat first open source company to top $1bn a year http://read.bi/GZ3PPT

One of the most advanced MySQL users in the world attracts some of the most advanced MySQL experts http://bit.ly/H7jlT8

Inspiring blog post on freedom by JP Rangaswami http://t.co/hnmeGvuH

Freedom without fragmentation in ecosystems with common APIs

I'm glad you keep saying it!

read more

apt-get install supybot
su - ircbot
mkdir supybot
cd supybot

supybot-wizard

supybot configurationfile.conf

wget https://launchpad.net/meetbot/0.1.4/0.1.4/+download/meetbot-0.1.4.tgz
tar -xzvf meetbot-0.1.4.tgz
mv meetbot ~/supybot/plugins/

Supybot: load MeetBot

• mull - an IRC-only nick that dates back to my college days, maybe 1999-ish, when folks in the #aalug channel were trying out new nicks daily for a while.  I have no idea why this stuck, and I've never used it anywhere else. UPDATE: I've now claimed "agrimm" on IRC, so you won't be seeing "mull" anymore.


• arg - I made a particularly huge mistake when I chose my initials for my FAS (Fedora Account System) ID, even though there was very little possibility I'd be able to use that elsewhere.   I suspect that a FAS account is one of the less trivial ones to change, too, so I'm probably stuck with this being a one-off.


• agrimm - the obvious first initial + last name choice, more easily obtained than initials, but still not universally unique.  I use it for email addresses and not much else, and I get a *lot* of misdirected email for people who share my last name.


• a13m - I started using this for twitter and some other random things when arg and agrimm were taken.  In case it's not obvious, this nick derives from my full name, in the style of i18n, a11y, etc.  While very short and almost never taken by anyone else, the relation to my name is subtle enough that most people don't make the connection.

In Greg's Where is Waldo game, one big event was missing: Eucalyptus is also at UDS. Harold, Brian and me are already in Oakland ready to rock and roll. We have exciting news for our session: you can check out Brian's blog for a sneak peak of  Eucalyptus 3.1 Alpha1. Your favorite on-premise IaaS now is available with HA, boot from EBS, and IAM (check the roadmap for more details).

read more

import json
from restkit import Resource, BasicAuth, Connection, request
from socketpool import ConnectionPool

pool = ConnectionPool(factory=Connection)
serverurl="https://api.github.com"

# Add your username and password here, or prompt for them
auth=BasicAuth(user, password)

# Use your basic auth to request a token
# This is just an example from http://developer.github.com/v3/
authreqdata = { "scopes": [ "public_repo" ], "
                note": "admin script" }
resource = Resource('https://api.github.com/authorizations', 
                    pool=pool, filters=[auth])
response = resource.post(headers={ "Content-Type": "application/json" }, 
                         payload=json.dumps(authreqdata))
token = json.loads(response.body_string())['token']

"""
Once you have a token, you can pass that in the Authorization header
You can store this in a cache and throw away the user/password
This is just an example query.  See http://developer.github.com/v3/ 
for more about the url structure
"""
resource = Resource('https://api.github.com/user/repos', pool=pool)
headers = {'Content-Type' : 'application/json' }
headers['Authorization'] = 'token %s' % token
response = resource.get(headers = headers)
repos = json.loads(response.body_string())

For those of you who missed us in New York and the Bay Area this week, never fear.  We’re getting around.    Come see us at:

• April 28 – 29: LinuxFest Northwest, Bellingham WA
• April 30 – May 2: OpenCloudConf, Sunnyvale CA
• May 6 – 10: Interop Las Vegas – Mandalay Bay, Las Vegas, NV
• May 8: Goldman Sachs Cloud Computing Conference – Rosewood Sand Hill, Menlo Park CA
• May 16: AWS User Group Amsterdam – Amsterdam, Netherlands

Find the person in the Eucalyptus t-shirt / white dress shirt / hoodie and say hello.  Check out our full events schedule.  If you’ve got an event you’d like to add to that list, let me know.

For those of you who missed us in New York and the Bay Area this week, never fear.  We’re getting around.    Come see us at:

• April 28 – 29: LinuxFest Northwest, Bellingham WA
• April 30 – May 2: OpenCloudConf, Sunnyvale CA
• May 6 – 10: Interop Las Vegas – Mandalay Bay, Las Vegas, NV
• May 8: Goldman Sachs Cloud Computing Conference – Rosewood Sand Hill, Menlo Park CA
• May 16: AWS User Group Amsterdam – Amsterdam, Netherlands

Find the person in the Eucalyptus t-shirt / white dress shirt / hoodie and say hello.  Check out our full events schedule.  If you’ve got an event you’d like to add to that list, let me know.

read more

Aaaand now that all the transcripts are in and somewhat cleaned up, here is the complete collection of EucaDay artifacts; if you wanted to know what happened during any of the Eucalyptus sessions, everything you need is below. It is all text-based so it is easy to search and translate (there are no audio or video files available). If new artifacts come in, I will update this post accordingly.

If you are catching up with the event now, I suggest reading the transcripts (there are two) as a primary activity since they are a live capture of what was said during the event, then opening the other artifacts (slides and videos) as they are mentioned in the transcript.

Morning transcript – a running log of what was said during (and around) Marten’s and Tim’s presentations, including audience questions. Use this as your primary reading to catch up on the morning.

Marten’s slides (presented in the morning) – Marten Mickos is the CEO of Eucalyptus, and gave an overview of where the company is and where it’s headed.

Tim’s slides (presented in the morning) – Tim Cramer is the VP of Engineering at Eucalyptus, and talked about the state of Eucalyptus technical development.

Morning IRC backchannel log - what was being discussed on IRC during Tim and Marten’s talks.

Afternoon transcript – a running log of what was said during (and around) Greg’s presentation, including audience questions, and the EucaDay wrap-up by Marten. Use this as your primary reading to catch up on the afternoon.

Greg’s slides (presented in the afternoon) – Greg DeKoenigsberg is the VP of Community at Eucalyptus, and talked about why a thriving open source community is vital to Eucalyptus — and then let community members take the floor through short filmclips.

Videos (shown in the afternoon) in the order they were shown:

• Osamu Habuka on his Eucalyptus book
• Patrick Dunnigan on Storm
• Paul Weiss on moving a cloud from Amazon to Eucalyptus
• Imran Hossain Shaon on Nilgiri

Afternoon IRC backchannel logs- what was being discussed on IRC during the Community session.

Feel free to edit and comment on any of the transcripts and artifacts — and let us know whether this sort of event documentation is useful, and whether we should do it again!

1. They must be in the same project as their parent
2. They must have the same permissions (issue-level security) as their parent
3. They must be of an issue type that is flagged as a "subtask" type, so for example, a "Feature" cannot be a subtask of a "Story" unless you create a separate "Feature (subtask)" issues type.

#!/usr/bin/python

import sys
import pyjira
from jiranemo import jiracfg

# Set the exception hook to enter a debugger on
# uncaught exceptions
from jiranemo.lib import util
sys.excepthook = util.genExcepthook(debug=True,
                                    debugCtrlC=True)

# Read ${HOME}/.jirarc, and set up clients and auth caches.
cfg = jiracfg.JiraConfiguration(readConfigFiles=True)
authorizer = pyjira.auth.CachingInteractiveAuthorizer(cfg.authCache)
ccAuthorizer = pyjira.auth.CookieCachingInteractiveAuthorizer(cfg.cookieCache)
client = pyjira.JiraClient(cfg.wsdl, 
                           (cfg.user, cfg.password), 
                           authorizer=authorizer, 
                           webAuthorizer=ccAuthorizer)

# Do a simple JQL query via the SOAP client, return 20 results
issues = client.client.getIssuesFromJqlSearch(
    '''project = "system testing 2" order by Rank DESC''', 20)
for x in issues:
    # Get the REST representation of each issue, because links
    # aren't shown in the SOAP representation
    rest_issue = client.restclient.get_issue(x.key)

    for link in rest_issue['fields']['issuelinks']:
      if link['type'].has_key('inward') and \
         link['type']['inward'] == "is blocked by":
        # Rank the linked issue above this one in Greenhopper
        result = client.restclient.gh_rank(link['inwardIssue']['key'], 
                                           before=rest_issue['key'])

Couldn’t make it to New York to see Greg DeKoenigsberg’s Community session at the first EucaDay this afternoon? No worries, this post series has it all, including the mini film festival in the middle!

First, I’ll include the entire slidedeck (you can click through to slideshare and download the deck as a pdf as well). Then I’ll show each individual slide inline with the transcript of Greg’s talk and each of the videos that were shown.

So we’ll go ahead and get started. I’m Greg DeKoenisberg. And this is the Euca community bar…

…except that’s a lie. We were talking about this being the bar part. Apparently it’s too early to start drinking so — I guess. There’s time and time. Just relax. It’s at the end of the day. This is — I always sort of love and hate getting the session at the end of the day because everyone’s been hanging out and we’ll try to keep it interesting and light and if I don’t succeed in that, feel free to get up and wander off. Trust me, I’m not going to be the least bit offended.

There you go. Can you read that? Get your eyes checked. It said welcome EucaDay NYC attendees. That’s what it said. So that’s 6 point font, I think.

The community says hello, there’s a lot more of them than there are of us right now. That’s very clear. It’s — like 9 point font, I think. And that’s supposed to represent some notion of proportionality. My role is to design the Euca community so I care about the community. And constituency is very much a virtual constituency. So even though we’re all here today having a lovely time on Wall Street, there are people all over everywhere who care about what it is that we’re doing and part of my job so to make sure that we’re being as transparent a company as we possibly can be.

So for some of our sessions here we have made sure that we have a transcriptionist who is doing all of this in realtime over the Internet so that the people who are not in this room can be in some sense in this room because they are every bit as important as we are.

So I’d like to talk a little bit about what makes open source projects ultimately
successful. And there are three things that I think are key success factors for an open source project I will give you all the opportunity to guess at what these may be because that’s active and fun and any guesses on what one of the three key success factors of the project is? A great community, no, it’s not. That’s really not it. Openness.

Openness is good. I’m looking for one particular word first. Let’s see if anyone can come up with it. What conspiracy, what? Users. Users. Users. Right? If software has no users, it’s very difficult to build a community. So what’s the second thing?

Audience member: Developers.

No, users. And then the third thing is users.

Users, users, users, all other things are important but, if you have no users, you have no product, no community, no nothing. Users are what we make software for.

There was a great programmer named George Bernard Shaw. This is a quote about software. The reasonable user adapts to software. The unreasonable user adapts the software to himself. All progress is dependent on the unreasonable user.

I’m thinking of getting a bumper sticker made because to me unreasonable users are the things that make open source communities work. And if you’ve ever been in an open source community, you know that there are a certain number of unreasonable users in every one of them, right? But that’s a good thing because they’re the ones trying to bend the world to their own needs.

They are what Eric von Hippel would call lead users. There’s a great book called Democratizing Iinnovation. The URL is at the bottom here. If you want to understand how software works, there’s great stuff there. But as far as how open innovation actually works, this was a book that’s been very formative to the way I think about open source software. So I recommend it. And it talks basically about how lead users drive innovations. And I’m not going to get too much into that because I don’t want to take up all your time talking about someone else’s book but it’s a really good book, I highly recommend it.

So what I care about specifically at Eucalyptus right now is getting users to move up the open source pyramid.

And at the base of this, of course, is users. So we had some responsibilities to our users to get them on to the pyramid, to make sure that there’s something useful for them to actually use, first of all, right? Any open source projects has to have functional stable code and that’s what we can focus on for most of our existence. Right?

It has to do something that’s useful. It has to work. It has to install properly. Has to do these basic things. Because until it does that, it’s interesting, it’s busy, it’s a cool project but until there’s code that does stuff that the user needs, it’s not really open source software yet, right? It’s just a project — it’s just a project idea.

So this is what we’ve been focused on for quite a while. To get as many users as we possibly can, we’re racing, racing, racing to the Eucalyptus 3.1 session. For those who you who were here this morning, this is what we talked about this is where we bring the open source and enterprise part back together. Currently they’re forked, they’re going to be the same code base again in 3.1. That is was going to allow us to get as much penetration as we possibly with a stable product that does all the things that our users need that can be easily installed, quickly installed, configured to do all the useful things that they needed to do. And one of the most useful cases of coarse is as an on-premise AWS compatible product, that’s what a lot of our users are looking for.

But we are in open source, right? In people who participate in the open source world. Lots and lots of users. Most users will simply remain that. Not everyone wants to move up this pyramid, right? But it’s my job to make sure that those who are interested in moving up this pyramid, a lot of people are users, they’re perfectly happy being users. They will gain great value out of our product. Some of them will become customers so they can be supported. That’s good too.

But then a certain number are going to have questions and they’re not going to be satisfied with whatever documentation we have or what have you. So they’re going to start looking for knowledge. This is how people grow into open source communities. They start trying to figure things out. So we need to make sure that we are serving those people. We need to make sure that we’ve got great knowledge based articles. We’ve got great forms for them to interact and we’ve got ways for them to reach out and touch us as a company beyond simply the “I’m a customer who needs support, I want to buy a subscription” kind of relationship. There are people who want to reach out in different ways than that.

We recently launched a site called engage.eucalyptus.com. I recommend you check it out if you’re at a place that has reliable Wi-Fi. Not that it doesn’t here. And we hang out here in IR C. How many people know what that is? That’s a decent percentage. That’s good. That’s where open source developers tend to live. We live on irc.freenode.net. We’re on the #Eucalyptus channel. You can go to webchat.freenode.net and get on to IRC without having to have an IRC client.

A little bit of chicken and egg there if you don’t know how to get on IRC, you can’t ask someone on IRC to help you but there are good web interfaces out there. That’s a little diversion here. Most of the people I know on the Eucalyptus community think of them first by their IRC nickname. In some cases I don’t actually know what their real names are. But I know they seek to engage us in the mediums that they are comfortable in and we need to make sure that we are there to engage them in those ways. Right?

So then you move up. This isn’t actually a change of gear. This is just the next highest level up the pyramid but my transition — I’m terrible at slides. So I was going to have a little transition that was going to zoom up the pyramid. I don’t know how to do that. So some number of these people who find whatever knowledge it is that they’re looking for or maybe they don’t find the right kind of knowledge, maybe they had a suggestion, maybe they have a bug. Maybe they got a great feature idea. Maybe they want to partner with us on something. Maybe something really made them angry and they just want to shout at someone.

All of these are means of participation. And without participation, there can be no open source community and without an open source community, there can ultimately be no open source company or at least it’s not going to be really an open source company. Right?

So we need to make sure that we have infrastructure to serve these potential participants. And we need to make sure that when they present themselves as participants, we are super super responsive to them. Right? Because people don’t want to waste their time.

If people come to your community and say I am interested in participating in some way, giving you a patch, exploring a bug with you to figure out with you why it doesn’t work — because I could just ignore the bug and say this is just a piece thrash trash and I’m not going to use it. I’m a user, my time is valuable. I found a bug, now I’m bringing it to you. What are you going to do about it? We must be hyper-responsive.

And for people who are looking for help it’s nice if we can give them some kind of recognition, right? So this is what we’ve been working on in the last little while. As we build out the open source community around Eucalyptus, we’ve got a site called projects.eucalyptus.com where we’ve got a lot of open source projects that are more thoughtful in some ways to the main product and we’ll go over those in a little bit. Also as Tim mention earlier, we’re opening up our engineering process.

Right now the bug tracker we have is somewhat outdated. Most issues are from the 2.X time frame in the next little while we’re going to roll out a public bugtracker that’s going to have issues from the 3.X releases and then we’ll be moving our source out to github in the very soon to get ready for 3.1, right?

And then obviously IRC as we just mentioned is a key part of being hyper responsive. I got a little script that any time anyone says my name on IRC, it sends me an e-mail and a text that said someone pinged you on IRC. And I don’t turn that off. Sometimes I sleep through it. But I don’t turn that off. So any time anyone says “Greg, what are you doing on IRC?” I will see it unless I’m asleep or drunk or ignoring them.

Which I try not to do. I try to be hyper responsive.

And then we also have mailing lists for people who want to have conversations about things that we care about. So, if you go to lists.eucalyptus.com you can see that mailing lists tend to be… “I have this problem that I’d like to work with you on, I saw you were doing code stuff, I’d like to know more about that.” Sort of a different mechanism.

And then reward takes many forms. For our super high flying community folks we have sweet hoodies that we had made that has Euca and if I weren’t in New York, I would probably be wearing that instead of this. But I have it in my bag so, if anyone is super excited to see it I can go to the hotel and get it and wear it while we’re drinking. But also just thank you. Just thank you. Thank you for using our product. Thank you for filing a bug. Thank you for saying that terrible thing about us on the forum. We know you didn’t really mean it. And if you did, let’s talk about that.

You know?

And then at that point you get a level of contributors who become your core contributors over time. People who really make difference in your project. People who go from users all the way to the top and become core contributors. People just as useful to your company as any employee you might have. And we’re still bringing people down that road. We’re starting to see people bubble up that stack. And what they care about is being equal in agency to the people in the company. Right? And there’s a lot of talk in open source about what’s your governance model going to be. How are you going to make sure all these competing influences are heard and from my perspective, that has always been fairly simple. Who’s writing code and how are you treating it?

And mostly, that’s what people care about. You know? They don’t care about how much money company X or organization Y has to pay to be a quote, unquote member of your community. They care about what you do with their contributions. And if you contribute code and they say — I’ll look at that in a while, that’s enraging. If they contribute code, and you look at that code and say “okay, so thanks for this patch. It’s really cool. This is broken, this is broken. This is formatted way wrong, you’ve got guidelines over here, I’m really not sure what’s going on with this, you need to take a look at that. But, if you can take care of all that stuff and bring that patch back, we’ll be happy to put it in a main line.”

Developers really respond to that, right? That’s agency. Right? And then responsibility is when they get that code into your product, they want to know that they’ve got some piece of the action. Right? It’s all open source code so they can fork it any time they want that’s the thing that makes open source software interesting. Anybody can take all of that code and just walk away with it tomorrow and start their own project. So you want to make sure that they’re working with you and not forking to work against you.

And the way you do that is by giving them agency and responsibility. And then at a certain point someone’s going to ask for a job. And by this point, you should give it to them. Or if you can’t give it to them, you should make sure that they’re well recommended to get a job somewhere else or if they’re working with the partner organization, you know, you got a good relationship with them that opens up business opportunities for them. In my experience, and I worked with Red Hat for a decade, and was deeply involved with the Fedora project — this is how open source actually works. This is what we’re trying to build here at Eucalyptus. I think we’re being more successful every day.

But it’s our responsibility to build those steps. Right? People don’t just decide to participate in open source. You have to pull them in. You have to make a project that is a good strong open source project that it sends people to participate and make their way to the top. So I’ve talked quite enough.

I am literally posting this while Greg continues speaking at the front of the room – the talk is underway as I type. This level of detail in the capture was possible because, as Greg mentioned earlier, we’re live-transcribing EucaDay with CART today. I’ll write more about this later in an event wrap-up post, but I wanted to show the power that this sort of access enables.

Stay tuned for Part II: The Film Festival!

it all started with me lazily skimming through pages on the eucalyptus site yesterday, soon i landed on GSOC page since this is something whose results have been announced just yesterday too , from here i moved on to there next page Eucalyptus ideas page  , read on there website that they are have been not given the GSOC slots ,there idea number two is implemented here Eucalyptus users map , do send me feedback as to how it looks and works , in the meantime if you are interested in the first cut i tried making yesterday using the Wp plugin below is that version too
 

deependra.shekhawat@eucalyptus.com

Show embedded map in full-screen mode

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.

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.)

read more

Chef is a tool used for configuration management of bare metal and virtual systems. Chef has a client/server model as well as a standalone tool that is very similar to the tools from Puppet Labs. (Want to automate a puppet agent installation? Check out my earlier blog post

When using the cloud and launching multiple instances with the same job, configuration management is a huge time saver. Configuration management systems will allow you to build the configuration once and use it to create exact replicas on as many instances as you need. Having the exact same configuration for every system doing the same job keeps errors and possible issues down to a minimum. Also, if your production systems are easily replicated, you can spin up smaller test environments to check your systems before pushing out the newer code to production (possibly even using Amazon for production and Eucalyptus internally for testing!).

For configuration of systems, chef uses recipes and cookbooks to give users pre-made system configurations. A recipe is a single task and cookbook is a group of tasks, usually pertaining to a single application (e.g. apache, nginx, etc). A collection of pre-made cookbooks can be downloaded from a GitHub repository run by OpsCode, the creators of Chef. These cookbooks will help you a perform a large number of installations and configurations from setting up a web server to installing applications such as vim.

Below is a script that will automate the installation of the chef-solo, a standalone version of the chef client, on a CentOS 5 system. You can run this script by hand or have it automatically run by passing to the metadata service when running an instance. This script was tested on the Eucalyptus Community Cloud using a CentOS 5 image (emi-709D1676)

#!/usr/bin/env bash

YUM=`which yum`
RPM=`which rpm`
CURL=`which curl`
HOSTNAME=`which hostname`
RUBY=""
GEM=""

SYSTEM_NAME="chef.mydomain.int"
SHORT_NAME=`echo ${SYSTEM_NAME} | cut -d'.' -f1`

TMP_DIR="/tmp/"
DEFAULT_DIR="/root/"

CHEF=""
CHEF_DIR="/var/chef-solo/"

#######
# Set the hostname of the system.
#######
hostname ${SYSTEM_NAME}
if [ -z `cat /etc/sysconfig/network | grep HOSTNAME` ]; then
    echo "HOSTNAME=${SYSTEM_NAME}" >> /etc/sysconfig/network
else
    sed -i -e "s/\(HOSTNAME=\).*/\1${SYSTEM_NAME}/" /etc/sysconfig/network
fi

sed -i -e "s/\(localhost.localdomain\)/${SYSTEM_NAME} ${SHORT_NAME} \1/" /etc/hosts

${YUM} -y update

#######
# Setup the required repos. EPEL, Aegisco, and rbel.
#######
${CURL} -o /etc/yum.repos.d/aegisco.repo http://rpm.aegisco.com/aegisco/el5/aegisco.repo

${RPM} -Uhv http://rbel.frameos.org/rbel5

${CURL} -o ${DEFAULT_DIR}/epel-release-5-4.noarch.rpm http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
${RPM} -Uhv ${DEFAULT_DIR}/epel-release-5-4.noarch.rpm 

########
# Install ruby and required tools for building the system
########
${YUM} install -y ruby-1.8.7.352 ruby-libs-1.8.7.352 ruby-devel.x86_64 ruby-ri ruby-rdoc ruby-shadow gcc gcc-c++ automake autoconf make curl dmidecode

RUBY=`which ruby`
########
# Setup RubyGems
########
curl -o ${TMP_DIR}/rubygems-1.8.10.tgz http://production.cf.rubygems.org/rubygems/rubygems-1.8.10.tgz 
tar xzvf ${TMP_DIR}/rubygems-1.8.10.tgz -C ${TMP_DIR}
${RUBY} ${TMP_DIR}/rubygems-1.8.10/setup.rb --no-format-executable

GEM=`which gem`
########
# Setup the chef ruby gem
########
${GEM} install chef --no-ri --no-rdoc

CHEF=`which chef-solo`
########
# Setup the basic configuration files needed
########
cat >>${DEFAULT_DIR}/solo.rb <>${DEFAULT_DIR}/node.json <<EOF
{
    "run_list": [ "recipe[apache2]" ]
}
EOF

########
# Setup up cookbooks directory for chef solo
########
mkdir -p ${CHEF_DIR}/cookbooks

########
# Download and untar the cookbooks provided by OpsCode on GitHub
########
${CURL} -o ${DEFAULT_DIR}/cookbooks.tgz https://nodeload.github.com/opscode/cookbooks/tarball/master
tar xzvf ${DEFAULT_DIR}/cookbooks.tgz -C ${DEFAULT_DIR}

########
# Add the apache2 cookbook to the chef solo cookbooks directory
########
cp -R ${DEFAULT_DIR}/opscode-cookbooks-*/apache2 ${CHEF_DIR}/cookbooks

########
# Run the node.rb JSON file to install apache2
########
${CHEF} -c ${DEFAULT_DIR}/solo.rb -j ${DEFAULT_DIR}/node.json 

This script will need a couple changes towards the end to be used as with chef-client and communicate with a chef server. Hopefully in a future post this will be discussed.

This script uses the chef-solo version of the chef-client that does not require a chef server. This makes testing out chef much easier. Utilizing the GitHub cookbooks repository, we can install anything available in the cookbooks along with the customized configuration that we might need. Please check out the chef-solo wiki for more details on how to extend the script above to do more for you.

With the addition of Amazon S3 or Eucalyptus Walrus or GitHub this script can be used to work with customized cookbooks to improve your infrastructure even more.

Not really interested in CentOS 5? Looking for the same for CentOS 6 or Debian? Check out my GitHub repo containing my blog scripts for two additional scripts in the chef_solo_install folder. (Note: The majority of the OpsCode cookbooks are built for Debian (probably more specifically Ubuntu) based systems so some won’t work with CentOS 6 out of the box. There are also some issues with CentOS 5 with cookbooks such as the nginx one.)

For those who don’t know, I work on the euca2ools suite of command line tools for interacting with Eucalyptus and Amazon Web Services clouds on Launchpad. As of late the project has stagnated somewhat, due in part to the sheer number of different tools it includes. Nearly every command one can send to a server that uses Amazon’s APIs should have at least one corresponding command line tool, making development of euca2ools’ code repetitive and error-prone.

Today this is going to end.

But before we get to that part, let’s chronicle how euca2ools got to where they are today.

The Past

Early euca2ools versions employed the popular boto Python library to do their heavy lifting. Each tool of this sort triggers a long chain of events:

• The tool translates data from the command line into its internal data structures.
• The tool translates its internal data into the form that boto expects and then hands it off to boto.
• Boto translates the data into the form that the server expects and then sends it to the server.
• When the server responds, boto translates its response into a packaged form that is useful for programming and returns it to the tool.
• The tool immediately tears that version back apart and translates it into a text-based form that can go back to the command line.

Things shouldn’t be this convoluted. Not in Python.

The Present

Tackling this problem involved coming up with ways to simplify not only the code, but also the process through which they are written. This led to two major changes, upon which all of the current euca2ools code is built.

“eucacommand”

The first step was consolidating all of the code involved in performing the first step of this process — reading data from the command line — into one location. Each tool then simply needed to describe what it expected to receive from the command line, and the shared code would take care of the rest. For example, let’s look at part of an older command, euca-create-volume:

class CreateVolume(EucaCommand):
    Description = 'Creates a volume in a specified availability zone.'
    Options = [Param(name='size', short_name='s', long_name='size',
                     optional=True, ptype='integer',
                     doc='size of the volume (in GiB).'),
               Param(name='snapshot', long_name='snapshot',
                     optional=True, ptype='string',
                     doc="""snapshot id to create the volume from.
                     Either size or snapshot can be specified (not both)."""),
               Param(name='zone', short_name='z', long_name='zone',
                     optional=False, ptype='string',
                     doc='availability zone to create the volume in')]

Because there are three Params the shared code library reads three bits of info from the command line and hands them to the command’s code, which then hands them to boto, and so on.

This methodology forms the basis for all of the current euca2ools that begin with “euca”.

Roboto

For a euca2ools command line tool to be useful it has to gather data from the command line, send these data to the server, and return data from the server to the user. A little-known boto sub-project written by boto developer (and former euca2ools developer) Mitch Garnaat, roboto, takes this statement literally and opts to let tools work at a lower level: instead of translating data from the command line into an intermediate format to send to boto, tools send these data directly to the server in the form that the server expects. The effect of this is that of essentially removing boto from the euca2ools code base altogether. By removing boto from the path that data have to take to get from the command line to the server and back, roboto makes tool writing and debugging simpler because there is less code to walk through and understand.

Roboto is the basis for all of the current euca2ools that begin with “euare”.

The Future

That is the state of the code today. Where do we go from here? While roboto allows one to create command line tools with a minimal amount of effort, it has several rough edges which prevented it from taking off and which make it sub-optimal for building out the hundreds of commands that the euca2ools suite will soon need to cover:

• User-unfriendly — When a user types something wrong or forgets to include something, roboto’s messages are often uselessly terse and unhelpful.
• A steeper learning curve than necessary — Roboto contains a large amount of custom code dedicated to fetching information from the command line. This steepens the learning curve for people who want to contribute code or fix bugs.
• Too much hardcoding — Roboto assumes that all tools do certain things, such as ascertaining what keys they should use to access the cloud, the same way.
• Still more work than it has to be — Though it makes writing tools simpler, roboto still hands each tool a bucket of information and expects the tool to pick out the bits the server needs and send them onward.

Enter requestbuilder

Requestbuilder is a new Python library that attempts to rethink the way roboto works in a way that is more familiar to the typical Python developer and requires less custom code to run. The easiest way to illustrate this is with an example.

A command line tool embodies a specific request to the server, so each such tool defines a Request that describes how it works:

class ListUsers(EuareRequest):
    Description = 'List the users who start with a specific path'
    Args = [Arg('-p', '--prefix', dest='PathPrefix', metavar='PREFIX',
                help='list only users whose paths begin with a prefix'),
            Arg('--max-items', type=int, dest='MaxItems',
                help='limit the number of results')]

    def main(self):
        return self.send()

    def print_result(self, result):
        for user in result['Users']:
            print user['Arn']

Those familiar with Python’s argparse library will recognize the code inside Arg(...), because requestbuilder does away with roboto’s custom code for reading things off the command line and instead lets argparse do the work. This cuts down on the amount of code we need to maintain, makes tool writing easier for developers who are already familiar with the Python standard library, and makes command line-related error messages much more user-friendly.

When the tool starts running, requestbuilder uses data from the command line to fill in a dictionary called args and runs the tool’s main method, whose job is to process this information and fill in the portions of the request that will be sent to the server: params, headers, and post_data, and then run the send method to send it all to the server and retrieve a response. Attaching each of these sets of data to the request instead of passing them around between methods allows one to send a request, tweak it, and send the tweaked version as well.

Why doesn’t the code above fill any of these things in? Since most of the data that comes off the command line goes directly to the server, when a tool runs send requestbuilder will automatically fill in params from the contents of args so the tool doesn’t have to: whatever the user supplied with --prefix at the command line gets sent to the server with the name PathPrefix, and so forth.

But what if something should not be sent to the server? While data from the command line go into params to be sent to the server by default, one can tell requestbuilder to send a particular bit of data elsewhere instead:

Arg('--debug', action='store_true', route_to=None)

None instructs requestbuilder to leave the “debug” flag alone and not attempt to send it anywhere. Data can also go elsewhere, such as to the connection that gets set up as the tool contacts the server:

Arg('-I', '--access-key-id', dest='aws_access_key_id', route_to=CONNECTION)

Astute readers will note that I haven’t described what EuareRequest in the earlier example does, so here is the code for that:

class EuareRequest(BaseRequest):
    ServiceClass = Euare
    Args = [Arg('--delegate', dest='DelegateAccount', metavar='ACCOUNT',
                help='''[Eucalyptus extension] run this command as another
                        account (only usable by cloud administrators)''')]

Requestbuilder makes tool writers’ jobs easier by allowing one type of request to inherit its command line options from another type of request and then supply their own by simply listing more of them. This is a little different from the way Python usually works; Requestbuilder does some magic behind the scenes to make this possible. As a result, everything common to commands that access the EUARE service (Eucalyptus’s equivalent of Amazon’s IAM service) can go into one place to be shared with others.

The final piece of information requestbuilder needs is a ServiceClass, which describes the web service that the tool connects to. A service class is another simple bit of code that looks like this:

class Euare(BaseService):
    Description = 'Eucalyptus User, Authorization and Reporting Environment'
    APIVersion = '2010-05-08'
    EnvURL = 'EUARE_URL'

The net gain from all this is a smaller, but much more flexible code base that should be able to scale better than anything we have had before. Requestbuilder’s use of Python’s argparse library also makes tools much more informative to users than ever before.

How You Can Help

We’re developing requestbuilder on GitHub as a project under the boto organization. We’re going to start rewriting euca2ools, one by one, improving requestbuilder to support new things as we go. It’s still early on, so if you have ideas to share or you’re interested in helping develop this code, now is your chance!

We’re also moving development of euca2ools itself to GitHub. This will make it easier to work on euca2ools and requestbuilder in parallel. It will also make it easier to share code with the rest of the boto community.

If you’re interested in getting involved, join us on the #boto or #eucalyptus IRC channels on Freenode. You can also send e-mail to Eucalyptus’s community list.

In March, we announced an agreement to collaborate with Amazon Web Services (AWS) to ensure API compatibility between AWS and the Eucalyptus open source on-premise Infrastructure as a Service (IaaS) platform. Beyond the details of the news, I'd like to shed some light on how I think this agreement helps customers focus on the larger discussion of the policies and business logic that govern application workloads.

For some time now, Eucalyptus users have implemented application deployments using a combination of Amazon AWS and locally owned resources. Indeed, the original use case for Eucalyptus was to support large-scale science applications that could draw resources simultaneously from AWS and a geographically distributed set of data centers, each operated by a separate organization.

read more

The cloud world has been quite the spectacle lately.  Intrigue, romance, alliances and double-crosses, comedy, tragedy, and zombies.  If you’ve seen the play already, I won’t bore you by recounting it — and if you haven’t, I won’t ruin it for you.

At Eucalyptus, we continue to care most about, and focus chiefly on, making open source cloud software that works for our users.  So let’s set aside the theatrics and talk about users for a moment.

Some of you may be familiar with the U.S. National Institute of Standards and Technology, or NIST for short.  They’ve taken quite an interest in cloud computing.  In fact, they decided to come up with a definition for the term “cloud computing”.  And when a standards body like NIST decides to define something, they are thorough.  As in, sixteen drafts worth of thorough.  This work culminated with The NIST Definition of Cloud Computing, published in October 2011.

As it happens, NIST also wants to build their own cloud infrastructure.  To that end, they’ve put out an RFQ.  Here’s what they’re looking for:

“The Enterprise Systems Division (ESD) of the Office of Information Systems Management (OISM) at the National Institute of Standards and Technology (NIST) is seeking to obtain cloud management software to deploy a hybrid private (on-premise) and public cloud Infrastructure as a Service (IaaS) that uses NIST’s existing VMware ESX infrastructure and supports AWS-compatible public cloud resources.  ESD’s goal is to offer NIST’s Scientists an on-demand, self-service portal to IT resources using NIST’s own IT resources and IT resources in public cloud space.”

And what technology has NIST chosen?  The only one that currently fits the bill: Eucalyptus.  Again, from the RFQ:

“There are many cloud products in the market place, but NIST has determined Eucalyptus Enterprise Edition is the only IaaS cloud management software currently on the market that is built open source and supports private and public cloud infrastructure.”

The cloud market is moving fast.  Lots of competition, lots of churn, and lots of talk.  But we believe that code talks loudest.  We will continue to let our code, and our users, talk for us.

The cloud world has been quite the spectacle lately.  Intrigue, romance, alliances and double-crosses, comedy, tragedy, and zombies.  If you’ve seen the play already, I won’t bore you by recounting it — and if you haven’t, I won’t ruin it for you.

At Eucalyptus, we continue to care most about, and focus chiefly on, making open source cloud software that works for our users.  So let’s set aside the theatrics and talk about users for a moment.

Some of you may be familiar with the U.S. National Institute of Standards and Technology, or NIST for short.  They’ve taken quite an interest in cloud computing.  In fact, they decided to come up with a definition for the term “cloud computing”.  And when a standards body like NIST decides to define something, they are thorough.  As in, sixteen drafts worth of thorough.  This work culminated with The NIST Definition of Cloud Computing, published in October 2011.

read more

With the agreement between Eucalyptus and Amazon to cooperate on ensuring API fidelity between the two technologies comes the question of defining what it means for two independent implementations to support the same API. The API itself consists of a large number of different "commands" or "service requests," each of which triggers many different operations within the system that are visible to the user. Moreover, the API makes specific assumptions about "things" (VMs, storage volumes, network addresses, etc.) it is defining and manipulating.

read more

HA with OpeniSCSI:

Further to my general musings about HA, good chum Harold Spencer and I have been working on providing a way for our users to achieve high availability in the storage controller components of Eucalyptus for those who don’t have the SAN adapter.  The storage controller is the Eucalyptus component which handles the EBS (Eucalyptus Block Storage) volumes for instances.

Let me give some background here …..

With 3.0, we’re still following our old business model, this is effectively an Enterprise Edition for us.  This is all changing with the upcoming 3.1 release, as our good friend and colleague Greg outlines here.  This is a really big deal for Eucalyptus and also very exciting, we’re going back to our unified code-base.  The only things which won’t be open are a couple of proprietary subscription-only modules; one for VMware and one for interfacing with enterprise-class storage arrays (aka SAN’s). In regards to HA, those using Eucalyptus who don’t have a subscription can use HA for the Cloud Controller components (read my last blog entry on why that’s important) but won’t currently be able to use HA with the Storage Controller since this can only be achieved with an enterprise-class storage array and the subscription-only SAN adapter.  By default, without the SAN adapter, Eucalyptus uses the open-iSCSI target daemon (tgt) to handle EBS volumes.

We still think our users will want SC HA using open-iSCSI and we want to ensure that those users who don’t have a SAN (or don’t need the performance one brings) or who don’t pay our salaries can still have some kind of high availability experience at the storage level using some of the service and infrastructure HA platforms out there for Linux.  After all, running an open-iSCSI target daemon as a resource on top of a Linux clustering solution is nothing new and works very well of course.  In our testing we’ve been using pacemaker + corosync and running tgtd as a resource on top of a DRBD backed logical volume across a two-node cluster.  It just works, you can fail over LUN’s whilst clients are writing data to them and only achieve a brief wait at the client before disk operations can continue on the migrated LUN.  Data integrity is handled by the proper failover of resources and the excellent DRBD solution, courtesy of the great guys at Linbit.

You’ll want to check out Harold’s blog here for some more details on the work we’ve been doing to try to integrate this.

In my previous job, I spent a fair amount of time with enterprise customers who were – more often than not – moving from proprietary Unix to Linux.  Coming from Unix, these customers were often heavy users of resource(or service)-based High Availability (HA) products; such as HP Service Guard, Sun Cluster, Veritas Cluster Server etc.  When moving to Linux, they wanted feature parity with their traditional Unix HA technologies and they ran very Enterprise-level workloads; like database, CRM, and so on. More often than not, they would end up running Red Hat Cluster Suite (HA Addon) or SUSE High Availability Extension; both of which are paid add-ons for these distributions where you pay an additional support premium on top of your normal subscription.  These two stacks are of course open source, so you can go and download pacemaker, corosync and other tools and use them to keep your own services highly available at no cost.  Of course, there are other proprietary products available for Linux like SIOS LifeKeeper and HP Service Guard for Linux.  The latter is back from the dead due to popular demand.

I use the term resource-based in the previous paragraph to describe the nature of the HA solution; install the software on one host, then install your application and configure an active/passive failover environment across multiple servers.  Upon failure of the service on one node, the resource management and infrastructure layers will detect failure(s) and move the service resources (i.e. your application and dependencies, like a floating IP) across to the second node, with a small window of downtime.  The applications you run on top of such clustering layers are often not built with high availability in mind. Rather the application itself is blissfully unaware that it’s in some highly available configuration and instead the data and configuration is mirrored with underlying technologies, like DRBD.  This is where you want a really good cluster resource manager, like pacemaker and the important infrastructure layer, such as corosync and openAIS, to handle things in bullet-proof fashion.  These technologies have good mission-critical references too, Deutsche Flugsicherung (German Air Traffic Control) run their systems on top of SLES High Availability Extension, for example.   I’ll refer to this as service & infrastructure HA.

Then we have another way of achieving HA.  This is what some term as in-built HA, whereby the application itself has high availability features built into it.  A widely known example would be Oracle’s RAC product.  It’s UBER expensive but has differentiation over a simple active/passive Oracle DB running on top of one of the Linux HA stacks.  If your wallet permits, it allows you to scale out in large active/active database configurations.  This can be extremely useful for performance reasons whilst also achieving resilience.  These features are really useful for data warehousing and other demanding use cases where money is no object, like I dunno, utility billing or inland revenue and tax collection (har!).  Oh, did I mention cost?   You’re paying for a fair bit of development time and also features, you can do cool stuff that you just can’t do with the “normal” clustering products on Linux (and Oracle will ensure this stays the case).

With the release of Eucalyptus 3.0, we see Eucalyptus deliver the industries first cloud platform with in-built HA.  This is a big thing and something that enterprise customers need.  Whilst the notions and requirements of high availability in the cloud may be different depending on who you talk to, a customer will often require that their cloud be high availabilty to safeguard service level agreements (SLA’s) with users.

Furthermore, with 3.1, we’ll be enhancing flexibility further to give customers and users the option to run supported hybrid-HA topologies.  What do I mean by this?  Well, the Cloud Controller (frontend) and Walrus (S3) components can have redundant spares but the Cluster Controller and Storage Controler don’t, this saves on hardware costs and complexity for some.  It also unlocks an interesting possibility in terms of your SLA’s.  So, why would you want to do this?  Well, if an availiablity zone goes down, this might not bother you; users could just use another one in the timebeing until service is restored.  In the meantime you’d like to ensure users can still interact with the cloud and use a different availability zone, recovering their work from snapshots or data from bukkits (S3).  Without the Cloud Controller and Walrus, this wouldn’t be possible and this would be a much bigger issue for you; users wouldn’t be able to do *anything* and there goes your service.

Eucalyptus 3.0 HA lays the groundwork for flexible high availability in a truly distributed cloud platform.  It’s one to watch

1. Connect with community users on topics of interest for less formal learning sessions.
2. Accomplish the above with minimal tool requirements for the end-users/students.
3. Assess needed and currently available tools then determine how best to implement these in an automated fashion using best practices (what can be referred to as drinking our own champagne.)

Contributor Agreements have become a standard mechanism by which open source projects safeguard their rights to accept software into the project.  Canonical and Apache are just two illustrative examples.

The purpose of these agreements is to handle cases that open source licenses might not fully address.  For example: what does the project do if someone contributes code, and then later it turns out that the contributor didn’t actually own the code in question?  The typical Contributor Agreement answers this question by requiring the contributor to verify that they have the rights to contribute the code to the project.

There are, broadly speaking, two flavors of Contributor Agreements:

• A licensing agreement, in which the contributor holds the copyright for the code and provides a broad license to the project for the use of that code;
• An assignment agreement, in which the contributor assigns the copyright of the code to the project, and the project provides a broad license to the contributor for the use of that code.

The previous Eucalyptus agreement was an assignment agreement.  In order to commit software to the Eucalyptus project, a contributor had to agree to assign all copyrights and patents in the code to Eucalyptus Systems.

After careful consideration, and after working with counsel, we have decided to change to a licensing agreement.  This means that contributors will maintain ownership of their code and all associated IP, and license it broadly for use by Eucalyptus Systems.  We believe that this change is a crucial step that will make it easier for developers to contribute code to Eucalyptus.

We are in the process of making huge changes to our website, and incorporating the new licensing agreement will be part of those changes.  In the meantime, you can read the new agreements on our projects site.

Hi all,

I recently spent some time investigating this with my good colleague Andy Grimm. I had some initial issues in creating a RHEL6 image for KVM which would boot from EBS. Boot from EBS (sometimes referred to as bfEBS) is a new feature in Eucalyptus 3.X which allows a cloud administrator to back an instance with an EBS volume, thus giving persistence in the VM. This feature is present in AWS.

Below are some of my steps I used to create a RHEL6 guest image as a bfEBS volume. Note that I was using RHEL6 + KVM as the hypervisor:

1) Stop eucalyptus-nc on a designated host (or use another KVM host somewhere)
2) On the designated host, use qemu-img create to create a disk image:

qemu-img create -f raw rhel6_bfebs.img 2G

3) Set the disk label using parted: parted rhel6_bfebs.img mklabel msdos
4) Use virt-install to kick off a from-scratch installation:

virt-install --name rhel6-bfebs2 --ram 1024 --os-type linux --os-variant rhel6 \
-l http://192.168.7.65/rhel/releases/6.1/6Server/--disk \
path=/tmp/rhel6_bfebs.img,bus=virtio --vnc -x "lang=en_US keymap=us"

In your kickstart .cfg :

clearpart --all --drives=vda  --initlabel
 part / --size=512 --grow --fstype ext3 --ondisk=vda

Tweak as required

5) Complete the install then using virt-manager or other libvirt tool, start up the guest again (since finishing the install process is sometimes likely to shut it down, rather than reboot due to power mgmt).
6) Inside the guest:

7) On the instance, you can always mount the volume and check stuff:

hdparm -z /dev/vdX (re-read partition table)
 mount /dev/vdX /mnt/test

8) Make sure you unmount the EBS volume, if attached. Then detach the volume from the instance:

euca-detach-volume <volumeID>

9) Now snapshot the volume:

euca-create-snapshot<volumeID>

10) Register the snapshot (after it has completed):

euca-register -n "MyRHEL6bfEBS" -s <volumeID>

Done! Run your EBS-backed instance. Make sure that when you want to stop/start that you use the following commands:

euca-stop-instances
euca-start-instances

Otherwise, unless you’re using image attributes you’ll end up with the underlying volume being destroyed when you use euca-terminate-instances.  There goes your persistence

Installing dependencies on system

1. Check that Python 2.6 or greater is installed, in my case (Ubuntu 11.10) Python 2.7 is installed by default
2. Install python setup-tools and python-virtualenv

apt-get install python-setuptools python-virtualenv git

Creating your virtualenv and installing required modules

1. First create a fresh virtual Python environment in order to keep unwanted changes out of the main Python installation.  In my case I named it “eutester-dev”.
   • virtualenv eutester-dev
2. In order to enter the environment that was just created for you enter the following command
   • source eutester-dev/bin/activate
3. Now that we are in the virtualenv we can install the modules necessary for eutester
   • easy_install boto paramiko
4. Download eutester from githuband install it in the virtualenv
   • git clone git://github.com/eucalyptus/eutester.git
   • cd eutester
   • python setup.py install

Setting up your Eucarc file

1. If you are testing against Eucalyptus the credentials that were downloaded from the cloud are sufficient. Take note of the directory where the zip file was unzipped (ie the place where the eucarc file now resides). This path will be the “credpath” argument to the construction of your eutester or eucaops object.
2. If you are testing against a different AWS compatibile cloud the following must be provided in a file named eucarc:
   • export EC2_URL=http://mycloud.hostname.com:8773/services/Eucalyptus
   • export S3_URL=http://mywalrus.hostname.com:8773/services/Walrus
   • export EC2_ACCESS_KEY=’XXXXXXXXXXXXXXXX’
   • export EC2_SECRET_KEY=’XXXXXxXXXXXXXXXXXXXXXXX’
3. Make sure to put the correct hostnames for the EC2 and S3 URLs as well as the correct Secret and Access keys.

Max Spevack put together a great tutorial on setting up your environment for testing against EC2.

Configuring Python shell for tab complete and history

You should now be able to use your Python environment with eutester but in order to make development and testing easier you can use the Python shell with tab completion. To achieve this we will create a .pythonrc file in our users home directory that will allow setup the shell for us with tab complete every time we start it. Your ~/.pythonrc file should look something like this:

import atexit
import os
import readline
import rlcompleter

history = os.path.expanduser('~/.python_history')
readline.read_history_file(history)
readline.parse_and_bind('tab: complete')
atexit.register(readline.write_history_file, history)

Now add the PYTHONSTARTUP variable to your .bashrc (or equivalent) file and source the .bashrc:

echo export PYTHONSTARTUP=~/.pythonrc >> ~/.bashrc
source ~/.bashrc

Next well need to create the file to log our shell history:

touch ~/.python_history

Start the virtual Python environment shell using a call directly to the Python binary

~/eutester-dev/bin/python

You should now be able to hit TAB twice to see the available namespaces that you can use within the Python shell. For example, load up the Eucaops class then create a tester object, then type “tester.” and hit TAB twice. You should see a list of the properties and methods provided by the Eucaops class

ubuntu@ip-192-168-165-22:~$ ./eutester-dev/bin/python
Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from eucaops import Eucaops
>>> tester = Eucaops(credpath=”~/.euca”)

As noted on the Amazon Web Services Blog and the EC2 discussion forums, today is the release of the Amazon Linux AMI 2012.03.

You can check out the release notes for more information about new features.

If you are running the command line tools for accessing EC2, you can find the AMI IDs in your region by running:

$ euca-describe-images -o amazon | grep amzn-ami | grep 2012.03.1

Change euca- to ec2- if you are using the Amazon EC2 API Tools.

If you like what you see and want to help us build future versions of the Amazon Linux AMI, you should submit your resume!

I started making some notes on how EBS volume creation can be tracked and troubleshot in Eucalyptus (Eucalyptus 3.X + btw).  I figured this would make a good blog post, so I’ve just dumped all the information into here and I’ll let Google do the rest  I’ll update it as I go along and provide more hints in the troubleshooting section, this will also make it into the Eucalyptus Knowledge Base, albeit in different form and smaller chunks.  I hope this is useful to some.

Puppet is a very popular configuration management system. It allows users to deploy new infrastructure in a cloud or traditional enterprise environment quickly and efficiently. When an organization utilizes a configuration management system, it allows IT and DevOps groups to effectively replicate environments on the fly with little to no interaction with the new instance or system.

The basic building block for using puppet in the cloud is through the puppet agent. The puppet agent has two main actions:

• Applying a manifest to the systems it’s running on
• Working with a puppet master to coordinate a new deployment

In this post we will be focusing on the first aspect of the puppet agent mentioned above by using it in a standalone configuration.

What will our script do in this post?

• Update the instance
• Setup the hostname
• Install the puppet agent
• Create a manifest for the puppet agent to work with that will install vim and Apache2
• Apply the puppet manifest to the instance

All of these actions will be accomplished with a single command, euca-run-instances. With a simple deployment like this, we reduce complexity for new instance deployment and will give more power to cloud users. This has the side effect of making IT’s talk list much shorter, gives teams a quicker turn around time for new systems, and allows for new systems that are spun up to look exactly the same which reduces the possibility of errors.

For this post I’m going to use the Eucalyptus Community Cloud and a Debian Squeeze image (emi-00781826). Below is the script that will do what was outlined above. Copy it from here (or GitHub – Puppet Agent Install) and save it to your local machine for use.

#!/usr/bin/env bash

FULL_HOSTNAME="myhost.mydomain"
SHORT_HOST=`echo ${FULL_HOSTNAME} | cut -d'.' -f1`
APTITUDE=`which aptitude`
APT_KEY=`which apt-key`

###########
# Setup the hostname for the system. Puppet really relies on 
# the hostname so this must be done.
###########
hostname ${FULL_HOSTNAME}

sed -i -e "s/\(localhost.localdomain\)/${SHORT_HOST} ${FULL_HOSTNAME} \1/" /etc/hosts

###########
# Need to add in the aptitude workarounds for instances.
# * First disable dialog boxes for dpkg
# * Add the PPA for ec2-consistent-snapshot or else the update will hang.
###########
export DEBIAN_FRONTEND=noninteractive
export DEBIAN_PRIORITY=critical

${APT_KEY} adv --keyserver keyserver.ubuntu.com --recv-keys BE09C571

###########
# Update the instance and install the puppet agent
###########
${APTITUDE} update
${APTITUDE} -y safe-upgrade
${APTITUDE} -y install puppet

PUPPET=`which puppet`

##########
# Setup the puppet manifest in /root/my_manifest
##########
cat >>/root/my_manifest.pp <<EOF
package {
    'apache2': ensure => installed
}

service {
    'apache2':
        ensure => true,
        enable => true,
        require => Package['apache2']
}

package {
    'vim': ensure => installed
}
EOF

############
# Apply the puppet manifest
############
$PUPPET apply /root/my_manifest.pp

############
# End of script cleanup.
############
export DEBIAN_FRONTEND=dialog
export DEBIAN_PRIORITY=high

This script very pretty basic. First we take care of some basics like setting the hostname on the instance and we update the instance to the latest software available. We then install the puppet agent onto the system and find where the new binary is located. Next we create a file containing our puppet manifest that we wish to install and finally we apply the manifest to the instance.

To use the script with a new instance use the -f flag for euca-run-instances like so:

euca-run-instances -k <my_key> -t <instance_size> -f <path_to_script> emi-00781826

This is just a basic example of how you can utilize puppet inside of your Eucalyptus or EC2 compliant cloud with a metadata service.

(Looking to try this out with CentOS? There’s a script for it on GitHut – Puppet Agent Install. Try it out on the ECC with EMI emi-709D1676.)

Edit: I’ve added a CentOS 6 script for this as well now. Check it out at the GitHub repo above!

  Spent yesterday evening with awesome group of Eucalyptus enthusiasts in Delhi. Those few brave souls which manged to defy the Delhi traffic and still managed to make it to the lush green IIT Delhi campus.

  The day started with Deependra Singh Shekhawat, who works with Eucalyptus as Support Engineer, dropping in at my office around noon time. After feasting over pizza’s and breads we started out for the venue along with Himanshu Anand.

 By the time we reached venue it was all set except, the room we were allocated was locked. After sorting out some confusions we got access to the class room and it turned out, the room was three times bigger than what we had asked for. But at the same time, the room was equipped with a projector and all other facilities.

 Just when we were about to start, it turned out that Deependra’s macbook had a DVI port and the projector supported only VGA. To add to this, we had no DVI to VGA converters. But things cant go wrong technology wise, when you are with a bunch of techies. We quickly connected another laptop to to the projector and connected Deependra’s laptop to first laptop over remote desktop.
  Hence we were set to start. We started with introduction and experiences of audience members with cloud computing. It turned out during introductions that Abhishek Gupta, one of the co-host of the event and a student of third year Computer Science and Engineering at IIT Delhi, has written a cloud controller as an academic project and IIT Delhi is running a cloud setup based on that controller as an experiment in one of the labs.

 After Abhishek finished his introduction to his academic project, Deepnedra started with his presentation on Eucalyptus. In the meantime, we were joined by Tarun Dua, one of the co-founders of E2Enetworks.com . The presentation from Deepndra was good and it turned more into brainstorming and discussions than a normal presentation. The discussions were so engaging that I forgot to click pictures

 The presentation was filled with cross questions from audience and lots of inquiries about the features of eucalyptus. Broadly these are the features that audience was interested in

• Billing module so that one can charge or atleast calculate the usage of the resources.
• Integration with SAN. Though Eucalyptus supports SAN integration, it is limited to specific SAN devices. We would like to see support for more SAN protocols such as AOE, FCoE, iSCSI and FCP.
• Support for Hyper V
• Support for more programming languages for writing plugins in Eucalyptus, specially perl.

 We also discussed few of the security scenarios generic to clouds such as bot-nets, DDoS attack, attacks by exploiting vulnerabilities and cloud outages. Thoug we had no conclusive answers to these. But was still worth discussing.

  The most interesting discussion we had was on SAAS definition in cloud environment. This is where the whole audience was split in two groups. One group claiming that SAAS is when you can configure and customize software to your need, while everyone shares the same codebase V/S if you are running any software in cloud, it is software as a service. The discussion was inconclusive and we moved on to other items in the presentation.

 Overall this meetup helped everyone by deepening the knowledge of eucalyptus as well as eucalyptus deployments. Specially the part where Deependra explained few use cases of organizing CLC, cluster controllers and node controllers.

 I also learned few new things about Eucalyptus from this meetup. I was not aware of VM-islotation , which allows you to run separate VM on a separate VLAN and the VM’s cannot talk to each other when they are separated by VLANs. Also learned that Eucalyptus doesnt support VTP, though I am not yet sure if this support has to go in Eucalyptus stack or in networking gear’s firmware.

Post meetup, we landed up in a restaurant and ordered Brownie-Truffle cake with “Eucalyputs 3.0″ written on it. The cake was delicious and everyone had no options except for licking fingers. That is because, firstly it was awesome and secondly I had already signaled the the staff not to serve spoons . The dinner was good with a goofup where a guy mistakenly ordered 4 times the quantity of breads required and we ended up with this basket of breads, which we could not finish…

Know it has been a long post, so I will leave you guys with link to handful of pics fromat he meetup. Did not click much as I was busy with discussions.

Pics: First Eucalyptus meetup -Delhi

One question still remains unanswered though. Why is amazon innovating in cloud space and we are not ?

I often sit at my desk, with my eyes closed, hands rubbing against a face in desperate need of a shave, contemplating a dilemma. We face the challenge of building a support organization that can scale to meet our customer’s needs and I can’t help but think we’re missing something. Something that can redefine how we engage with our customers, something that can make their experience that much more meaningful. And just as I feel like I’ve reached my wits end, in walks Graziano with the perfect solution to my dilemma – our community. Eucalyptus has an amazing community. One that is eager to help and spread the word about cloud computing. This is summarized best by Graziano in his blog post about One Eucalyptus Community.

Eucalyptus represents more than just a product. Eucalyptus is a group of individuals who believe that together we can have a lasting impact upon the landscape of cloud infrastructure. But this group is not made up of just the employees, founders, or the management team. Eucalyptus is made up of thousands of individuals who have dared to challenge the status quo of infrastructure operations; individuals who believe that together we can make a difference.

So last year we decided to challenge our thinking around customer support and find a better way to bring these groups together, to build one customer, one community. We began the process by looking at what mattered most for our users. This was broken down in to 3 basic categories – ease of use, user experience, and integration. Over the following 5 months, we generated a detailed list of over 50 requirements, receiving input from multiple Eucalyptus and community individuals and organizations, and then organized those requirements into a priority list. We then began the lengthy process of evaluating over half a dozen community and support facing tools and concepts and narrowed the list down to a handful of options. We then identified the solution that we felt provided us the greatest flexibility in bridging our community and customers into one positive user experience.

I am pleased to announce that over the first half of 2012, in conjunction with the launch of our new OneSite and Eucalyptus 3 software, we will be unveiling a new technical support website that will encourage all Eucalyptus users to ask, search, and engage with Eucalyptus. We will make it easier for users to sign-up, participate, and join our community. Whether you are under a support contract or just interested in information or asking questions, our goal is to provide all users with the best possible experience.

Graziano’s blog was about listening to our community, and striving to be better. I would like to raise that bar higher by challenging all of us to embrace each other as members of the Eucalyptus community, and work together to share knowledge, encourage discussions, raise issues, and be part of one of the biggest technology game changers of our life time.

Automation is a huge piece of any successful cloud deployment. When you have the ability to scale horizontally with seemingly “infinite” resources you need a quick and automatic method of setting up additional services. Infrastructure-as-a-Service cloud services, such as Amazon EC2 or Eucalyptus, have built-in functionality that allows for information to be passed to new instances and allows for complete system automation.

The two main technologies that assist the cloud user or cloud developer with an automation task are the following:

• Metadata service
• Automated user data execution

The metadata service allows the user to supply an instance with information regarding it’s setup, environment, and data provided by the user through the cloud service (For more information see Amazon EC2 Instance Metadata or Eucalyptus Metadata Service). This ability to pass data to a new instance gives the user a simple method for automating the instance’s setup without needing to ever login to the instance. The user’s data, kept at http://169.254.169.254/latest/user-data by the metadata service, can contain a script that, with the proper setup on the instance’s image, can be executed automatically as the instance boots.

To achieve automatic execution of the user data from the metadata service, we can utilize a couple different methods. The first method involves running commands inside of the /etc/rc.local file of an instance’s image. The most basic version of an /etc/rc.local that will automate the execution of user data is the following:

curl -s -o /tmp/user-data http://169.254.169.254/latest/user-data 
sh /tmp/user-data

In the above code snippet, we first download the user data from the metadata service at http://169.254.169.254/latest/user-data and place it into a temporary file. Then we execute the user data using a basic POSIX shell. This is only the most basic form. You can find a more sophisticated /etc/rc.local implementation in the Eucalyptus Starter Images.

An emerging standard method for downloading and utilizing the user data is with CloudInit. CloudInit takes the above /etc/rc.local functionality and extends it greatly. It is definitely worth it to research CloudInit’s features and use it with a Debian or Ubuntu based image and hopefully in the near future Fedora and Centos as well.

This was simple a basic primer on how the metadata service of an IaaS cloud service functions behind what the cloud user will see. In my next post, I’ll show how to use the metadata service to do some basic instance setup automation.

Introduction

In my time working for Eucalyptus, I have begun the Eutester project that aims to provide the framework for cloud architects and administrators to validate and benchmark their various AWS-compatible cloud infrastructure options.  Enterprises and research institutions are rushing to roll out their strategies for moving their mission critical applications and services to on-premise, public, or hybrid clouds. The end result of this strategy should be a fault tolerant and reliable compute, storage, and networking infrastructure. Unfortunately, choosing a private or hybrid IaaS solution to implement is not the end of the road for a cloud strategy. The next level of planning involves choosing and validating the interconnected components of the cloud infrastructure stack. The considerations necessary include, but are not limited to, choosing network topologies, hypervisors, component topology, and storage devices. What many  will end up with is a few different ways to implement the end goal, a scalable and robust self service infrastructure. In order to make “apples to apples” comparisons of these options, it is necessary to have a test library that is agnostic to the underlying components and treats each cloud implementation equally by presenting results in a unified and comparable way.

Eutester Basics

Eutester is written in Python and leverages the boto and paramiko libraries to provide the necessary tools for quickly implementing an automated test strategy. Boto is used in order to provide connections to EC2, S3, and IAM. Paramiko is leveraged to provide root access to nodes that are running the individual cloud components. The eutester module is separated into two main classes: eutester, which provides the necessary logic to get a test bootstrapped, and eucaops, which inherits from eutester and provides predefined routines that can validate operations against the cloud. Here is an example of the difference in using the eutester class by itself rather than using eucaops. Notice that when using both eutester and eucaops you have full access to the underlying EC2 and S3 connections provided by boto.

>>> from eutester import Eutester
>>> from eucaops import Eucaops
>>> eutester = Eutester(credpath="../credentials")
>>> eucaops = Eucaops(credpath="../credentials")
>>> eutester.ec2.get_all_images()
[Image:eri-168B3564, Image:eki-E9A03638, Image:emi-5D824306, Image:emi-30823A1C]
>>> eucaops.get_emi()
Image:emi-5D824306
>>> eucaops.ec2.get_all_images()
[Image:eri-168B3564, Image:eki-E9A03638, Image:emi-5D824306, Image:emi-30823A1C]

As you can see the only required parameter to get a test up and running is simply the path to a credentials directory that contains a eucarc file that can be used to extract both the access and secret keys as well as the hostname of the EC2 and S3 implementation. In the case of Eucalyptus these are the Cloud Controller and Walrus. Once the boto connections have been established the testing is ready to begin and you can start to send commands to the cloud:

>>> emi = eucaops.get_emi()
>>> reservation = eucaops.run_instance(emi)
[2012-03-04 17:46:42,205] [EUTESTER] [DEBUG]: Attempting to run image Image:emi-5D824306 in group default
[2012-03-04 17:46:42,976] [EUTESTER] [DEBUG]: Beginning poll loop for the 1 found in Reservation:r-F4F842A4
[2012-03-04 17:46:42,976] [EUTESTER] [DEBUG]: Beginning poll loop for instance Instance:i-87FB415E to go to running
[2012-03-04 17:48:16,953] [EUTESTER] [DEBUG]: Instance(i-87FB415E) State(running) Poll(9) time elapsed (93)
[2012-03-04 17:48:16,953] [EUTESTER] [DEBUG]: Instance:i-87FB415E is now in running
[2012-03-04 17:48:16,953] [EUTESTER] [DEBUG]: Instance i-87FB415E now in running state


The output here shows that the instance we ran successfully went to the running state, as expected. Once the instance is running it may be useful to ping the instance from the test machine to ensure we have connectivity.

>>> instance = reservation.instances[0]
>>> eucaops.ping(instance.public_dns_name, poll_count=1)
[2012-03-04 18:08:38,075] [EUTESTER] [DEBUG]: Attempting to ping 192.168.47.202
[2012-03-04 18:08:38,076] [EUTESTER] [DEBUG]: [root@localhost]# ping -c 1 192.168.47.202
[2012-03-04 18:08:48,081] [EUTESTER] [DEBUG]: PING 192.168.47.202 (192.168.47.202) 56(84) bytes of data.

— 192.168.47.202 ping statistics —
1 packets transmitted, 0 received, 100% packet loss, time 0ms

[2012-03-04 18:08:48,081] [EUTESTER] [CRITICAL]: Was unable to ping address
False

We were unable to ping the instance likely because the group that we launched it in, “default,” did not have the proper ports authorized. Lets go back and authorize the ports and retry the ping:

>>> eucaops.authorize_group_by_name(group_name="default", protocol="icmp",port="-1")
[2012-03-04 18:11:35,755] [EUTESTER] [DEBUG]: Attempting authorization of group
>>> eucaops.ping(instance.public_dns_name, poll_count=1)
[2012-03-04 18:12:18,445] [EUTESTER] [DEBUG]: Attempting to ping 192.168.47.202
[2012-03-04 18:12:18,445] [EUTESTER] [DEBUG]: [root@localhost]# ping -c 1 192.168.47.202
[2012-03-04 18:12:18,457] [EUTESTER] [DEBUG]: PING 192.168.47.202 (192.168.47.202) 56(84) bytes of data.
64 bytes from 192.168.47.202: icmp_seq=1 ttl=63 time=6.49 ms

— 192.168.47.202 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.498/6.498/6.498/0.000 ms

[2012-03-04 18:12:18,457] [EUTESTER] [DEBUG]: Was able to ping address
True

Now we can see that the instance is reachable. In these few steps we have validated the folllowing:

• Hypervisor is properly operating and can run VMs
• The image we used can boot and start networking properly
• Opening ports on a security group is working properly
• Networking from the CLC to CC and CC to Node controller is working as expected

These may seem like trivial checks but should not be taken for granted when first turning up an installation of a cloud platform.  Along with the checks of functionality we also received some benchmarks for this particular run instance request in which it shows that for the instance to go to running it took 93 seconds. If we rerun those few steps with various images we can get a feel for the performance of different images on the same cloud. Similarly if we use the same image against clouds running different hypervisors we can get a feel for the prep time each hypervisor requires to bring up an instance.

Here we have seen a case where things more or less worked as expected and were easy to debug and get running. When things are not quite working the way we expect, eutester allows you to start and stop monitoring the logs from all of your Eucalyptus components. This requires a slightly different initialization of the Eucaops or Eutester object wherein we include a root password for the Eucalyptus component nodes as well as a small configuration file that provides the topology of the components and thier hostnames. In my next blog post I’ll go over how Eutester can help you when your cloud is not functioning properly.

For an initial API doc please see:

https://github.com/eucalyptus/eutester/wiki/API-Documentation

Raise issues on the Github project page at:

https://github.com/eucalyptus/eutester/issues

All contributions are welcome, whether it be testing, refactoring code, new use cases, or added functionality.

Come hang out at #eucalyptus on freenode to discuss any topics related to Eutester or Eucalyptus in general.

"In Santa Barbara the only clouds are computer clouds"

After a nice 18 hour flight Anne and me arrived in San Francisco on Sunday night. Bags from claim and hit the road to Menlo Park, from where we had rented a room to settle in. We are living upstairs in the house of lovely couple in the neighborhood of Stanford University (social living is really common in well-crowded San Francisco Bay Area) . We didn’t have too much time to recover, because the next day was already our first work day.

My workweek started by biking to Palo Alto and opening a U.S. mobile subscription. After that, I had lunch with my boss including an introduction to my company Eucalyptus and the objectives of my internship. Introduction to U.S. business culture was the next in line: My boss asked if I’m able to fly to Santa Barbara the next day to join in on a training for new sale-hires. Sure, so after less than 2 days in the Bay Area I was on my way to the airport again.

In Santa Barbara, I faced an on-boarding experience which I would not have dared to expect. A three-day training, where an excellent session was followed by another, was some what a deep dive into the world of cloud computing. Private cloud infrastructure, server by server and hypervisor by hypervisor, became familiar as well as the company culture and vision. I was impressed and it was hard to believe that the company was founded just few years ago and one year ago it had no more than 15 employees.

Now with already 70 employees, Eucalyptus has still maintained its start-up attitude. On the eve of the new edition of software to be released, there was similar atmosphere in the office than children waiting for Christmas. For the new entrant, equal and “can-do” working culture combined with skilled individuals solving difficult problems, seems to be the reason why so many people enjoy work in start-ups. After one week I have just scratched the surface, but I am more than willing to scratch more.

Jussi
twitter @jussivaltonen

Little thought experiment today (pedagogy class is really getting to my brain): if I were creating a new-hire process for employees being assigned to work on an open source project, what would it look like? Here’s a first pass; it’s randomly improvised and not particularly well-thought-out, but fun anyhow; it’s partially based on what I’ve (unconsciously) come to find myself doing each time I’ve launched into a new open source project over the past few years.

You spend your first week as a remotee, no matter who you are or where you’ll end up working. You have exactly the same access to the tools and processes that a community member would have; no internal mailing lists, no magical “you’re hired therefore you get the root password” shortcuts. If you want privs, you need to earn them the same way as any community member (or in some cases, when the hire is from the community, they’ll have earned them already). During this week…

• You have constant access to orientation staff — hopefully in-person, but at the very least via a remote medium you’re already comfortable in. This is important; they’re your culture/tools coaches, and their encouragement will help you buffer the inevitable frustration you’re going to hit (new hires will be told ahead of time that it’s going to be frustrating).
• You’ll get training in remote collaboration tools if you don’t already know them. Your project’s IRC channels, bugtracker, wiki, version control system, etc… you’re going to learn to use them. By the end of the week, you’ll be lurking on your project’s IRC channel(s), your blog will be feeding into Planet (and you’ll have posted on it), you’ll have introduced yourself on mailing lists, edited the wiki, triaged bugs… This is a lot like the material we teach in POSSE (actually, you could remix POSSE into this portion of such an orientation).
• Ditto the above to open source culture. Things like “release early, release often,” “default to open,” open source business models, “ask forgiveness not permission,” and so forth will be brought up by your coaches.

The main point is that you’re going to try to start doing your job without any sort of magical special “I’m an employee” powers (other than the fact that you’re paid to work on this, which is a privilege that shouldn’t be discounted). Inevitably, you’ll run into issues; outdated documentation, discussions you can’t overhear because they happened inside an office and someone forgot to send notes to a mailing list, information trapped inside the heads of your coworkers. Since you want to get stuff done, you’re going to start poking your teammates to get documentation out there, to talk on IRC, to better practice the open source way and enable you to work as a “community contributor” — and if they do, they’re not just enabling you, they’re enabling the entire community.

And that’s your deliverable for the first week. You’re going to try to get work done, and it’s great if you can, but you’re probably going to end up with a list of “things I can’t access from the community world and need in order to do my job.” Some of the things on this list may be legitimately internal; I’m willing to bet a bunch of them will be externalizable. It’s going to be frustrating, but again, that’s the point; you’re going to experience exactly the same pain community members face, so that you’ll know firsthand why it’s so important to open them up once you do get “inside.”

Oh. And you’ll get through the normal new-hire paperwork and training (finance/payroll, legal, company history/vision/mission, etc) because some of that is stuff companies are legally obligated to do (I think).

You’ll actually be allowed inside the office at the start of your second week, but only for 4 days a week. You can join internal mailing lists now, see private documents, that sort of thing. But you’re still considered to be in training. Here’s what that means.

• You’ll still get ongoing modules on the culture/tools/practices of the open source way. Maybe you’ll run an IRC meeting and get feedback on your meeting-running skills. Maybe you’ll shadow a “community-experienced” coworker to see how he/she handles certain kinds of interactions and tools. Maybe you read a little writeup on the feature selection process in your open source community and then blog about it.
• When you learn something, you’ll document it as a record of your learning. Publicly when possible, on a shared internal wiki (or something) when not.
• That one day a week you’re not allowed in the office? That’s your “community shift.” You spend that shift helping community members get their stuff done. That list of “stuff I needed access to during my first week that wasn’t out in the open”? Fix it. Hang out on IRC and answer questions. Review patches. Reply to mailing list posts. Triage bugs and thank reporters. Do some wiki gardening. Go to an open source event. Screencast a tutorial. You get to expense lunch, and you have to write a blog post (that will go to your project’s Planet) about what you (and your team) have been up to for the week — the stuff you can talk about publicly, that is.

Practicing the open source way is something that takes time and experience because it’s a paradigm shift; it’s about how you see the world, the subtleties of how you interact with it, and its effects are usually not immediately apparent. That’s what you’ll learn here — it’s easy to tell you, but in order to observe it, you need to live it.

You’ll learn that “but I have nothing to contribute!” isn’t true (remember, this is for all new hires, not just engineers). You’ll learn that your beginner’s mind is sometimes your most valuable asset. You’ll learn how your work with the community can bring a lot of subtle little long-term leverage to your employer (and some not-so-subtle, huge, short-term wins, if you’re lucky). You’ll learn what it’s like to welcome new people to the community in turn, and how quickly even a newcomer can become an even newer newcomer’s “old hand” and mentor. You’ll learn how much energy can be unlocked when you release a blocker and enable community folks to do stuff they’re already rarin’ to do.

This phase lasts for… some defined period of time. 3 months, 6 months, “until the release cycle you joined during is finished,” whatever makes sense for that project. But at that point, you get your first review…

Your performance review is based on your public record. If it ain’t public, it don’t count. The things you’ll bring before your boss are things like your git commits, meetbot IRC logs, wiki edits, list threads… your public portfolio of open source participation. If you don’t have enough of a public record (where “enough” is some standard we define somehow — I told you this was off the top of my head) then you remain in “trainee” mode for another round.

Once you “graduate” from new-hire training, you’re no longer mandated to do “the open source way” training modules (or at least not constantly), and you’ll be allowed in the office anytime. Maybe your “community shift” will shorten (half a day instead of a full day every week?) or maybe, depending on your role, it might vanish (although I would love to see, for instance, the new lawyer or accountant continue to lurk in IRC, comment on mailing lists, and so forth). Maybe on-site workers will still be required to take one “remotee week” a year in order to remind them; remotees are already typically expected to make trips to headquarters to meet folks in person at least that often, so why not reverse it?

Again, raw thoughtdump. Plenty of holes, I’m sure. I’m curious what people think – especially people who have careers in open source, or want them. Is this an orientation you’d sign up for? Is this an orientation you’d like your coworkers to have?

• us-east-1: autoscaling.us-east-1.amazonaws.com
• us-west-1: autoscaling.us-west-1.amazonaws.com
• us-west-2: autoscaling.us-west-2.amazonaws.com
• sa-east-1: autoscaling.sa-east-1.amazonaws.com
• eu-west-1: autoscaling.eu-west-1.amazonaws.com
• ap-southeast-1: autoscaling.ap-southeast-1.amazonaws.com
• ap-northeast-1: autoscaling.ap-northeast-1.amazonaws.com

• us-east-1: cloudformation.us-east-1.amazonaws.com
• us-west-1: cloudformation.us-west-1.amazonaws.com
• us-west-2: cloudformation.us-west-2.amazonaws.com
• sa-east-1: cloudformation.sa-east-1.amazonaws.com
• eu-west-1: cloudformation.eu-west-1.amazonaws.com
• ap-southeast-1: cloudformation.ap-southeast-1.amazonaws.com
• ap-northeast-1: cloudformation.ap-northeast-1.amazonaws.com

• universal: cloudfront.amazonaws.com

• us-east-1: monitoring.us-east-1.amazonaws.com
• us-west-1: monitoring.us-west-1.amazonaws.com
• us-west-2: monitoring.us-west-2.amazonaws.com
• sa-east-1: monitoring.sa-east-1.amazonaws.com
• eu-west-1: monitoring.eu-west-1.amazonaws.com
• ap-southeast-1: monitoring.ap-southeast-1.amazonaws.com
• ap-northeast-1: monitoring.ap-northeast-1.amazonaws.com

• universal: ls.amazonaws.com

• us-east-1: dynamodb.us-east-1.amazonaws.com

• us-east-1: elasticache.us-east-1.amazonaws.com
• us-west-1: elasticache.us-west-1.amazonaws.com
• us-west-2: elasticache.us-west-2.amazonaws.com
• sa-east-1: elasticache.sa-east-1.amazonaws.com
• eu-west-1: elasticache.eu-west-1.amazonaws.com
• ap-southeast-1: elasticache.ap-southeast-1.amazonaws.com
• ap-northeast-1: elasticache.ap-northeast-1.amazonaws.com

• us-east-1: elasticbeanstalk.us-east-1.amazonaws.com

• us-east-1: ec2.us-east-1.amazonaws.com
• us-west-1: ec2.us-west-1.amazonaws.com
• us-west-2: ec2.us-west-2.amazonaws.com
• sa-east-1: ec2.sa-east-1.amazonaws.com
• eu-west-1: ec2.eu-west-1.amazonaws.com
• ap-southeast-1: ec2.ap-southeast-1.amazonaws.com
• ap-northeast-1: ec2.ap-northeast-1.amazonaws.com

• us-east-1: elasticloadbalancing.us-east-1.amazonaws.com
• us-west-1: elasticloadbalancing.us-west-1.amazonaws.com
• us-west-2: elasticloadbalancing.us-west-2.amazonaws.com
• sa-east-1: elasticloadbalancing.sa-east-1.amazonaws.com
• eu-west-1: elasticloadbalancing.eu-west-1.amazonaws.com
• ap-southeast-1: elasticloadbalancing.ap-southeast-1.amazonaws.com
• ap-northeast-1: elasticloadbalancing.ap-northeast-1.amazonaws.com

• us-east-1: elasticmapreduce.us-east-1.amazonaws.com
• us-west-1: elasticmapreduce.us-west-1.amazonaws.com
• us-west-2: elasticmapreduce.us-west-2.amazonaws.com
• sa-east-1: elasticmapreduce.sa-east-1.amazonaws.com
• eu-west-1: elasticmapreduce.eu-west-1.amazonaws.com
• ap-southeast-1: elasticmapreduce.ap-southeast-1.amazonaws.com
• ap-northeast-1: elasticmapreduce.ap-northeast-1.amazonaws.com

• sandbox: authorize.payments-sandbox.amazon.com/cobranded-ui/actions/start
• production: authorize.payments.amazon.com/cobranded-ui/actions/start
• sandbox: fps.sandbox.amazonaws.com
• production: fps.amazonaws.com

• universal: iam.amazonaws.com

• universal: importexport.amazonaws.com

• universal: mechanicalturk.amazonaws.com

• us-east-1: rds.us-east-1.amazonaws.com
• us-west-1: rds.us-west-1.amazonaws.com
• us-west-2: rds.us-west-2.amazonaws.com
• sa-east-1: rds.sa-east-1.amazonaws.com
• eu-west-1: rds.eu-west-1.amazonaws.com
• ap-southeast-1: rds.ap-southeast-1.amazonaws.com
• ap-northeast-1: rds.ap-northeast-1.amazonaws.com

• universal: route53.amazonaws.com

• universal: sts.amazonaws.com

• us-east-1: email.us-east-1.amazonaws.com

• us-east-1: sns.us-east-1.amazonaws.com
• us-west-1: sns.us-west-1.amazonaws.com
• us-west-2: sns.us-west-2.amazonaws.com
• sa-east-1: sns.sa-east-1.amazonaws.com
• eu-west-1: sns.eu-west-1.amazonaws.com
• ap-southeast-1: sns.ap-southeast-1.amazonaws.com
• ap-northeast-1: sns.ap-northeast-1.amazonaws.com

• us-east-1: sqs.us-east-1.amazonaws.com
• us-west-1: sqs.us-west-1.amazonaws.com
• us-west-2: sqs.us-west-2.amazonaws.com
• sa-east-1: sqs.sa-east-1.amazonaws.com
• eu-west-1: sqs.eu-west-1.amazonaws.com
• ap-southeast-1: sqs.ap-southeast-1.amazonaws.com
• ap-northeast-1: sqs.ap-northeast-1.amazonaws.com

• : s3.amazonaws.com
• us-west-1: s3-us-west-1.amazonaws.com
• us-west-2: s3-us-west-2.amazonaws.com
• sa-east-1: s3.sa-east-1.amazonaws.com
• eu-west-1: s3-eu-west-1.amazonaws.com
• ap-southeast-1: s3-ap-southeast-1.amazonaws.com
• ap-northeast-1: s3-ap-northeast-1.amazonaws.com

• us-east-1: sdb.amazonaws.com
• us-west-1: sdb.us-west-1.amazonaws.com
• us-west-2: sdb.us-west-2.amazonaws.com
• sa-east-1: sdb.sa-east-1.amazonaws.com
• eu-west-1: sdb.eu-west-1.amazonaws.com
• ap-southeast-1: sdb.ap-southeast-1.amazonaws.com
• ap-northeast-1: sdb.ap-northeast-1.amazonaws.com

• us-east-1: ec2.us-east-1.amazonaws.com
• us-west-1: ec2.us-west-1.amazonaws.com
• us-west-2: ec2.us-west-2.amazonaws.com
• sa-east-1: vpc.sa-east-1.amazonaws.com
• eu-west-1: ec2.eu-west-1.amazonaws.com
• ap-southeast-1: ec2.ap-southeast-1.amazonaws.com
• ap-northeast-1: ec2.ap-northeast-1.amazonaws.com