Posts that are eucalyptus-ish
Aaaand now that all the transcripts are in and somewhat cleaned up, and here is the complete collection of EucaDay artifacts; if you wanted to know what happened during any of the Eucalyptus sessions, clinic 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:
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!
Couldn’t make it to New York to see Greg DeKoenigsberg’s Community session at the first EucaDay this afternoon? No worries, unhealthy 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.
Gregdek @ EucaDay NYC
This is an epically long post, so click to see more below the jump. And click on each individual slide to enlarge it.
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, here what would it look like? Here’s a first pass; it’s randomly improvised and not particularly well-thought-out, adiposity 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?
I’ve gotten some feedback on my post on fielding common questions at your Eucalyptus talk since it came out nearly 2 weeks ago, more about and have updated the text accordingly — check it out if you’re curious. I was actually urged (by EuCa employees) to put pricing information there – a level of transparency that surprised even me.
I’d also like to give a shout-out to Dr. Karl Wurst, physician who some of you have seen around the Eucalyptus IRC channels recently. Karl chairs the CS department at Worcester State University and is a long-time member of the Teaching Open Source community who’s been getting his students involved in open source projects since 2010. He’s taking his junior/senior Software Development class into Eucalyptus as their spring term project, and they have taken on the challenge of testing eutester against the new 3.0 release – no small feat, considering that they’re testing new test software against newly-released software with no prior experience with the platform.
I predict the readability of Eucalyptus getting-started documentation will dramatically improve over the coming weeks as they progress – which is incredibly important if we want new folks to pick up on the project. Most people fail silently; if they can’t get something to work, they’ll quietly give up and go away, and you’ll never be the wiser. By committing to fail publicly and loudly, Karl’s class is taking a vital role (and one that requires no small amount of bravery). They speak for the people who won’t. And as newcomers, they’ll be able to write better explanations for other newcomers than all the old-timers out there. Fresh eyes are an asset; if you have them, use them.
His students are blogging as they go along, and it’s interesting to see their take on the project from a newcomer’s perspective. If you see them on IRC or the mailing lists, say hello and introduce them to whatever you’re working on – and if you see something interesting on their blogs, drop by and leave a comment. Those sorts of small contacts with the “real world” are ordinary everyday things to those of us who are used to the open source world (or heck, industry in general), but trust me; they’re absolutely magical the first time you start getting them as a student. (I still remember being awed as an undergrad that people were emailing me about things that weren’t homework.)
So welcome, Worcester State! Welcome to the wild and wooly wide, wide world of Eucalyptus. Glad you’re here.
Getting radical realtime transparency in a project can be slow and frustrating, healing especially in the beginning. Most folks don’t know this, generic but in order to have public conversations, rx leaders need to send out a ridiculous number of private messages to get things rolling. In fact, looking at my own inbox history for the past half-decade, I’ve sent anywhere between 2-20 private messages – on average (not maximum, average) – to get a single public message during the early stages of a project’s “open” life.
You really need to keep poking people in private asking them to put their messages public. It’s thankless and invisible work. It takes a while to build a new cultural habit, and for a while it’s going to seem like you’ll be doing this forever… but trust me, it will come. It’s going to take longer than you want it to, it’s going to take an unexpected route, but keep the faith – it will come.
There are three strategies it’s useful to have up your sleeve for times like this.
Start the conversation in private, then say something like “hey, this is really good, could you resend it to the public list and I’ll reply there?” This is good for starters if folks are new to the “default to open” concept and are reacting with great nervousness. This nervousness stems from wariness that they may not want to go public with some hypothetical future thing – in effect, worrying about a problem that hasn’t happened yet. Going this route allows beginners in radical transparency to look at something they’ve already written and assess the risk for only that specific situation – no unknowns here, no future commitments. After a few times of going “oh, I guess that retroactive transparency was okay!” it’s much easier to ask people to give “open by default” a chance.
Publicly announce that you’ll only respond to things sent to the public list. Reply to private emails with a reminder of this. This only works only if the people you’re trying to persuade are unable to route around you. It’s also a bit of a strongarm tactic, not appropriate for all situations and best used in moderation if at all. But if you’re a project manager, or an instructor, or a senior engineer, or something of the sort, you might be able to get away with it – and boy, folks learn fast this way.
Get others to help you with the nudges-to-public. Those 20 private emails to get a single public email? No reason why you’ve got to be the only one doing it. Train others to become Agents of Transparency as soon as you can, especially if they were once on the other side of the conversation. To begin with, ask them to work specific mailing lists, specific people, or specific conversation threads into the public eye – coach them from behind if needed. After a little while, they’ll be able to do it on their own – then just ask them to keep an eye out in general, and hey presto!
The key thing to keep in mind is that this is an investment. You’re putting resources into something that may not see returns for a little while. But the returns will come, and they’ll be worth it – when a project tips over into living, breathing, and practicing true realtime transparency, the results of the culture shift can be stunningly refreshing.
All right, order I know the open source world has fast turnaround times, side effects but this is just ridiculous. And awesome.
You may have seen my first attempt at a business card design for Eucalyptus community members. I sent it out thinking that maybe there would be feedback in a week or so, viagra buy and I’d crank out a v.2.0 then…
It took four hours.
I woke up this morning to find that Jef van Schendel, a design student in the Netherlands who hacks on Fedora, had taken my design draft and made an svg mockup with color matching, more whitespace, and better alignment. Simultaneously, David Butler, the VP of Marketing at Eucalyptus, dropped a “contributor” logo variant into my inbox.
And so less than 24 hours after the first design was posted, we have an infinitely better one. BAM.
Helpful hints for future Euca swag designers: Eucalyptus-blue is #003f5e or 0, 63, 94 in RGB, and Eucalyptus-green is #8cc63f or 140, 198, 63 in RGB. Also, here’s how to make custom colors in LibreOffice.
The LibreOffice file is available for download here. It’s basically Jef’s design converted to LibreOffice and using David’s logo. As with the first card design, you’ll need the Gillius ADF font – ttf-adf-gillius from Ubuntu repositories, adf-gillius-fonts in Fedora ones, or just download Gillius Collection fonts directly.
Finally, a reminder from Greg:
Because we don’t have our trademark policy yet, use of this design is restricted to those who have explicit permission to do so. Which we will give quite liberally, but still, that permission is legally required to ensure that we maintain legal control over our trademarks.
So if you want that permission, find us on IRC (#eucalyptus, irc.freenode.net) or the mailing list (http://lists.eucalyptus.com/cgi-bin/mailman/listinfo/community) and let us know of your intention to use these cards. If you’re even considering this, it’s likely to be a very brief conversation that ends with us saying “approved, go for it.”
Happy conferencing! And remember, release early, release often. You never know who’s watching!
Update 22 hours later: Jef and Dave sent in card and logo redesigns, approved and we now have a much-improved second version of the card, look which you should use instead. Thanks, prescription guys!
Folks, we’ve got a business card template. Here’s a preview.
Disclaimer: I’m not a graphic designer, as this template makes painfully obvious. I threw this together in 16 minutes (yes, I timed myself) so it’s a very basic design. The colors and fonts don’t even match the Eucalyptus logo. However, you can use this design to run a pre-cut business card sheet through a home or hotel printer, and that’s what we need, because people are going to events tomorrow. (Actually, at this hour, I think it may even be today already.)
The template is a LibreOffice file, so you’ll need that installed before you can edit it. (LibreOffice is cross-platform and commonly available in Linux distributions – OpenOffice would work too.)
You’ll also need Gillius ADF, a Libre font from the “Gillius Collection” – download it here. I chose this font because it’s also commonly available in the repositories of Linux distributions. Ubuntu calls it ttf-adf-gillius and Fedora calls it adf-gillius-fonts so you can yum or apt-get install to your heart’s content.
Once you have those prerequisites installed, head to this ticket to download the template. Enjoy – and if you know graphic design better than I do, please feel free to fix.
Update 2/20/2012 – after further discussion with EuCa folks, visit this site I’ve updated and expanded the responses below. Thanks to everyone who chimed in!
As the Eucalyptus community picks up steam, more and more folks who aren’t Eucalyptus employees are giving talks about EuCa at various events around the world – which is fantastic. How do we get everyone the information they need to give a successful talk? Ah, that’s the fun challenge.
Sometimes we just fill in gaps as we go along. For instance, Shaon’s talk, “Next generation cloud deployment: Self help is the best help!” just got accepted to SoftExpo 2012. Subsequently, a few of us had a spontaneous discussion on how to field a couple tricky questions when giving EuCa talks – the post below is based on these meeting logs. (Disclaimer: these represent individual opinions and don’t speak for Eucalyptus as a company, etc.)
Why is Eucalyptus using the Amazon API?
Because AWS is way farther ahead than the others, and we believe it to be the most worthy of focus. We may support other APIs in the future, but we prefer to focus now on the best API, and that’s AWS. See this post by Mark Shuttleworth for reference – it’s about OpenStack, but makes the same point.
Comments from Eucalpytus folks: “AWS is by far the most popular public cloud out there. I.e. it’s not just best, it is also the most common.
How much does Eucalyptus support cost?
Varies widely. Contact Eucalyptus for details.
I originally posted this without a number because I know companies are often hesitant to post that sort of pricing information on the web. After asking around within Eucalyptus, I found out they actually wanted to give a public answer – awesome! Therefore: if we change the question to “subscription” (not “support”), the answer is “It starts at $2,000 per server per year.”
What third party apps are available for Eucalyptus management?
There are a few options for apps that run on Eucalyptus and provide Amazon-RDS-like support. Three popular ones:
Providers of IaaS services need a usage monitoring tool. What does Eucalyptus offer?
There are hooks in Euca 3.0 for reporting usage; this is a new feature. We don’t have [public] details yet, but they will be in the docs when we release them (which will hopefully be soon).
In Euca 2.0, instances cannot be recovered once the node goes down. Is there any solution?
Boot from EBS is a new feature in Euca 3, and may be able to help with that problem somewhat. However, redundancy (multiple instances running at all times) is the way to survive instance failures. If you have multiple zones, start instances on all zones.
Instances are supposed to be expendable. HA (High Availability) is for the infrastructure: the app will still need to be designed with the cloud in mind to be fully HA. EBS and Walrus are the persistent storages to be used to keep the states and backup.
Wait, wouldn’t EBS and Walrus use more resources? I thought cloud was supposed to minimize resource usage.
Yep. HA wastes resources by design.
A Eucalyptus employee commented with a clarification here: I wouldn’t say that HA “wastes” resources. It of course uses more resources, but for a good and intended purpose. So it’s not a waste. I would say something like “there is nothing such as a free lunch. To have HA, you need redundancy, and redundancy requires its own resources.”
What are the alternatives to Eucalyptus, and why would someone choose Eucalyptus over them?
It was pointed out to me that the first question here needs to be “how do you define ‘alternatives’?” But in any case, here are a few.
- A suggested addition to the list: vCloud Director from VMware, which is also aimed at enterprise customers – but is not open source.
- Openstack: Broad community supported by many companies, modular design. Both a blessing and a curse. Openstack is much more a set of tools for building a cloud; Euca is cloud-in-a-box. And openstack, honestly, just isn’t as far along. (Additional community comments: it’s designed primarily for public clouds and doesn’t support the AWS API.)
- Cloudstack: Good product, good UI. Integration with AWS isn’t as good. (Additional community comments: it’s also mostly used by service providers, not enterprises.)
- Opennebula: Again, more of a toolkit approach. Not too many components — just more flexibility about how you put them together. Seems like Openstack and Opennebula are both good for the service provider market, and Euca and cloudstack are more all-inclusive products for the enterprise market.
That’s all we had time for — what other questions would you ask, and how would you answer these?