The OpenStack Blog Everything in & around OpenStack in written words.

This post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.

Wayne Walls is a Cloud Architect at Rackspace, where he evangelizes global cloud strategy. A tenured technology leader, Wayne has engineered complex technical solutions, delivered IT transformation plans, and implemented multiple training initiatives around cloud computing. Co-maintainer of the Rackspace Developer blog, Wayne is helping developers, engineers, and executives understand cloud technologies and how to turn that knowledge into tangible returns. He holds a B.S. of Information Systems and a B.A. of Economics from the University of Oklahoma. Follow him on Twitter at @waynewalls. 

1. Describe an interesting OpenStack deployment that you were part of, and why others ought to know about it. What made that project work? Tick?

Working at Rackspace gave me an interesting opportunity; I was able to work with OpenStack at a very early stage.  The first time I deployed OpenStack it was on the Austin release – the first OpenStack release – when Jordan Rinke and I were tasked with building an OpenStack cloud for the Bexar Design Summit in San Antonio.  If I recall correctly, Austin had roughly 1,000 lines of code and roughly five pages of documentation (compared to the now nearly 100,000 lines of code and fantastic wiki with hundreds of pages of helpful documentation available to newcomers – big props to Anne Gentle for helping the world OpenStack better).  After days of combing through the code to figure out what flags existed and what they did, we were able to stand up a six node cluster for the Friday “Deploy a Cloud” session.  Using QEMU, we were going to walk conference attendees thorough the process of deploying OpenStack…on OpenStack.  To make things even more interesting, Dell provided us a half-rack to deploy onto – a rack of prototype Dell C-series sleds running Ubuntu 10.04.

In review, here are a couple memories from our deployment:

• #openstack on freenode had about 50 people in there.  Someone named “vish” knew a ton about everything.
• There were multiple configuration files
  1. nova.conf
  2. nova-network.conf
  3. nova-manage.conf

• No OpenStack API, all EC2 API controlled with euca2ools
• No Glance; there was a service called nova-objectstore that acted as middleware that treated local disk as an S3 bucket.  This is how images were uploaded into OpenStack.
  • Finding an image to upload into OpenStack to boot was NOT EASY.
• The command that caused a ton of heartache (unable to ping or SSH to instance once booted):
  • euca-authorize -P icmp -t -1:-1 default
  • euca-authorize -P tcp -p 22 default
• Greg Althaus from Dell loves his khaki shorts

While digging though my notes on this project I found this small script we could use to redeploy our cloud in the event something went horribly wrong: http://paste.openstack.org/show/39512/ – this script evolved into the first ‘automated’ deployment tool for OpenStack.  Special thanks to Vish for writing “nova.sh,” the precursor to DevStack and Laurent Luce for helping us understand how it worked.  Lots of commands were directly lifted from here and made many operations folks around the world rejoice.

After reviewing the that script, I’m absolutely blown away by how far the project has come in terms of maturity, ease of use, and ease of deployment. And that’s after just three years.  I very much look forward to the next three years!

2. What is the most common misconception you hear about OpenStack?

“No one is using it in production.”  That’s baloney. Early on, companies  viewed OpenStack as a competitive advantage and were putting it into production. But they weren’t necessarily sharing that with the world.  As time passes more and more user stories are becoming public knowledge and hopefully this misconception will be dispelled. Just look at all of the customers who spoke at the last design Summit in Portland – a good number of them are running OpenStack in production.

3. What’s the most critical feature you think cloud software needs to be widely adopted over the next year? 

Authentication ties in to all OpenStack components.  The pace of innovation of OpenStack and its integrated and community projects is astounding.  From my perspective, the blocker to many companies adopting OpenStack and/or its supporting projects is the fact authentication is not fully baked and features are outpacing the ability to control access.

4. How would you suggest to someone that they should pick OpenStack for deployment? What is the most compelling argument for OpenStack in your mind?

Two main reasons:

1.  The community ecosystem is friendly, brilliant and engaging.  OpenStack is like a family, sure there are disagreements, but at the end of the day everyone is looking out for each other and wants to make OpenStack the best it can be for the world to use.

2.  Public, private and bare-metal – the hybrid cloud.  OpenStack unlocks the ability to pick the right place for your application to get the best benefit.  It’s a true hybrid cloud strategy.

5. What is your favorite productivity hack? Secret trick? Shortcut you’re slightly embarrassed to admit? 

If This Then That (IFTTT) is awesome.  Social media is a great way to keep up to date on all the things, but there is a lot of noise if you’re consuming data from multiple social networks, blogs, mailing lists, etc.  Using a service like IFTTT allows you to pick and choose how information is disseminated to you, and also how you can share information with your personal networks.

This post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.  

Anne Gentle works on the OpenStack project as a Content Stacker, collaborating on community documentation so that any organization can offer cloud computing capabilities using open source software. 

1. How do you describe OpenStack to your parents?

Honestly, I haven’t had to explain OpenStack in depth to my parents. My dad is an engineer and definitely influenced my interest in technology, bringing home all sorts of gadgets from work including a four-color pen plotter that filled up half our living room. My parents just know I’m working on an open source project where I get to experiment with community documentation. They also know I’m a Racker, and that we have a corporate office made from a repurposed suburban mall in San Antonio. When I explain my job to my siblings or friends, I just say cloud computing is like paying for electricity — you get what you need when you need it and pay for it as you go. Then they ask me what city I am traveling next with just a hint of jealousy in their voice.

2. What comment(s) have you received from users that made your proud of your work? When have you felt best about your work?

Once I went to a happy hour in Austin for a group of people getting training at Rackspace, and sat next to an ordinary man, who was attending the training. I introduced myself as the OpenStack documentation coordinator, and got the nicest response. At least I am going to take it that way. It was, “Thanks for trying to do the impossible.” I felt best about the API doc work after the Compute team documented about 90-some Compute API extensions  on the API reference site at http://api.openstack.org/api-ref.html. We are constantly trying to improve the end-user information for OpenStack and believe me, it’s not an easy or simple task.

3. What other OpenStack developers deserve a shout out for the work they’re doing in the community? Who are our unsung heroes? Your own?

Speaking of unsung heroes, I try to give shout-outs to doc contributors in my attempt-at-weekly update to the Openstack-docs mailing list. One shout-out I gave last year was to a guy named Josh in Iowa who took it upon himself to write an OpenStack glossary on the OpenStack wiki. With his permission I brought it into the docs repository for re-use across a bunch of documents as needed. It was as if it appeared out of thin air. I also agree with others who have said the translation teams are unsung heroes. Thanks to IBM and Daisy, Ying Chun Guo, we have a full documentation translation tool chain which she put together in about a year’s time. Having worked on internationalization projects for documentation in enterprise software companies in the past, I know that’s lightning fast to get from nothing to automation in 12 months. Daisy has been tireless in her efforts and definitely should be thanked for her efforts.

4. What are the essentials for someone just getting started with OpenStack? Sites? Books? Conferences? People?

I really like the voice and readability of the OpenStack Operations Guide, it’s knowledgeable yet approachable. You can find it at http://docs.openstack.org/ops.

Lately I feel it’s essential to attend an OpenStack Summit. My fellow Racker David Cramer who maintains our doc build tool worked on our doc tools for about 2 years before attending an OpenStack Summit. Once he went to the Portland Summit, he understood more about the community, the high stakes, and the hard work we have ahead of us. I introduced David to the Infrastructure team, a few coremudgeons as they’d like to be called, and I think that helped him form next steps for integrating even more with OpenStack’s way of working. Because OpenStack work really has a “way” of collaborating that can surprise even those familiar with open source due to it’s size, scope, and fast evolution.

5. What was your first commit or contribution and why did you make it?

Wow, I had to look on Launchpad to see what it was. It was fixing a typo in the Swift docs, on September 21, 2010. On the Getting Started page, development was spelled developemnt and I fixed it with https://code.launchpad.net/~annegentle/swift/lp644420. I made it because I was hired to coordinate and update OpenStack documentation. At the time we just had a Swift doc site, the Nova one didn’t really exist until the Bexar Summit if my memory serves me correctly. Wow we have come a long ways in three years. We now maintain over 30 individual “documents” for OpenStack documentation, whether it’s an API site, a dev docs site, or a book and web site.

This post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.  

Joe Topjian is a systems architect at Cybera where he is currently designing, deploying, and maintaining various cloud environments to help technology adoption in Alberta, Canada. Cybera has been using and deploying OpenStack since the Cactus release.

1. What do you do when you’re not obsessing over and working with OpenStack?

In late May, my wife and I became parents to an awesome little guy. We spend all of our time with him – not just for the obvious reason that he’s a newborn, but because it’s incredibly fun. I always try to have side projects going on which can range anywhere from Puppet to synthesizing sounds to catching up on reading.

2. What are the essentials for someone just getting started with OpenStack? Sites? Books? Conferences? People?

Docs.openstack.org, the OpenStack mailing list, and the OpenStack-Operators mailing list are invaluable resources.

In addition, I think there are two other key areas to help beginners:

First, I’ve found that the most essential thing for people new to OpenStack is to understand that it’s simply an orchestration service for various underlying technologies such as KVM, Xen, LVM, NFS, etc. You don’t need OpenStack to run a basic virtual machine server – it’s totally possible to manually maintain KVM, a collection of qemu images, and user access to the server, but it’d be a pain. OpenStack takes responsibility of these tasks and makes everything work together. This idea demystifies OpenStack and its components into something more understandable.

Secondly, when a beginner has read up on the basics of OpenStack and has built a small cloud or two, they usually have a ton of questions. I’ve had the opportunity to meet with groups of new OpenStack users and just let them ask questions for hours – literally hours. These meetings are great ways to boost their self-confidence about OpenStack.

3. What other OpenStack developers deserve a shout out for the work they’re doing in the community? Who are our unsung heroes? Your own?

Definitely the team I was part of to write the OpenStack Operations Guide: Tom Fifield, Anne Gentle, Lorin Hochstein, Jon Proulx, and Everett Toews. As well, the OpenStack-Docs crew. OpenStack can have a steep learning curve and to try to fully understand and document it from a user’s perspective is an extremely difficult thing to do. Their desire to help users learn and understand OpenStack is very inspiring and it’s one of the main reasons I contribute back as much as I can in return.

Sam Morrison and crew from NeCTAR. Sam’s always a step ahead of me. Most of the time when I find a bug in OpenStack, he has already opened a bug report just a few days prior.

4. Describe an interesting OpenStack deployment that you were part of, and why others ought to know about it. What made that project work? Tick?

DAIR helps entrepreneurs by providing a Canada-wide OpenStack cloud to develop on. We ran a pilot of DAIR using OpenStack Cactus between 2011 and 2012 and received a lot of help from the OpenStack community to get it off the ground. We published all tools and scripts used during the pilot in hopes that others would benefit.

In October of 2012, DAIR graduated to a production cloud running OpenStack Folsom. In the same tradition as the pilot, we’re sharing our architecture design, deployment scripts, and configuration management scripts with the community.

5. If you could only have one album as your hacking playlist for the rest of time — what album would it be and why?

The Orb’s Orbus Terrarum has been a favorite of mine since I was a teenager.

This post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.  

Mike Perez is a Senior Software Developer at DreamHost and core developer on the OpenStack Block storage project Cinder. Since attending the Bexar design summit and being a contributor in 2010, he has been hooked and lacks a life. His twitter handle is @thingee.

1. What is the most important contribution you’ve made that will make OpenStack users happy?

I contributed version 2 of the Cinder REST API. There were some great new features that came out of it, as well as some restructure changes to help continue development of separate versions of the API and tests. The most important thing to me in the whole change was to make sure that the upgrade was easy for both users and system administrators. I can pretty much say that everything you were able to do in version 1 works just as well in version 2. At the Havana summit in Portland, I had great feedback from different companies that were very happy with Cinder’s upgrade process. This doesn’t just stop with Cinder though. I feel like the conversations I had with other contributors at the summit were all very exciting – wanting to know my views, tips and tricks we did for compatibility that they wanted to bring to other projects.

2. What comment(s) have you received from users that made you proud of your work? When have you felt best about your work?

Documentation. When creating a new API it’s especially important for people to know how to communicate with it and what to expect.  I <strike>painfully</strike> very lovingly went through each command in all versions of the Cinder API and documented the possible responses and caveats. I can happily say we have version 1 and 2 of Cinder API documented as of Grizzly, along with the quick start reference guide. The praise at the summit was totally worth it, especially random people wanting to buy me a drink. I love that.

3. What do you think are the benefits of the open, community-driven approach to development?

First off, this couldn’t work without a great community. From IRC, to the mailing lists, to code reviews, to the summit, it’s all great communication and energy; that’s something OpenStack really shines in. One of the great things about our community is our diversity  in how we all come from different backgrounds and have different use cases. When you have a proposal at a summit, be prepared for semantic questions and edge cases. This, in my opinion, is commonly viewed as a negative thing in the community to hold back development. Instead I think we should feel positive about the wealth of knowledge we have to share and take advantage of it, but not lose focus of satisfying the basics of the use case and build off of it incrementally. With the number of users using my work today, it’s quite a relief to have this community backing me up.

4. If you could only have one album as your hacking playlist for the rest of time — what album would it be and why?

Trent Reznor and Atticus Ross soundtrack album from the movie The Social Network. It has some great tracks for concentrating on code reviews and getting motivated for a late night of fixing bugs and getting new features done. Plus it secretly makes me feel like such a hacker, like the young Mr. Zuckerberg in that one scene where he uses a Perl script to download images of his college mates. (lol) When I’m running Tempest tests, you can usually find me blasting Dope’N’Stack Cloud Anthem hoping for the best.

5. What is your favorite productivity hack? Secret trick? Shortcut you’re slightly embarrassed to admit? 

I have a couple. First off, this may not seem like a shortcut, but with the current state of things, it has allowed me to get up to speed faster. The Cinder developer documentation shows how things talk to each other using mostly flow charts. Flow charts are great, but they don’t explain a lot of the details, caveats, possible code paths, etc. So as a result I find myself using ipdb which exports Python Debugger features and gives some added features. I find myself putting a breakpoint at the beginning of a request being received by a service and just stepping through everything until I understand it. I also use a notepad to keep track of all the layers I’ve gone through. Yes, this notepad will be upstream someday in the Cinder developer documentation. 😉

Secondly, every code review I do, I check out the change and pull it up on my Vim editor.  The Vim plugin Syntastic basically highlights pylint and pep8 issues I’m going to report back to the author, so I can focus more on the implementation. I’ve gotten compliments on my thoroughness, but little do people know…