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.  

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…

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 Gordon was first introduced to OpenStack Cactus as an intern at Fujitsu Labs of America, and began actively contributing during Essex development while at Cloudscaling. He currently works solely on OpenStack as a member of nova-core and hacking-core on behalf of HP.

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

Start playing with it. When I first started using OpenStack, there was very little documentation and it took two of us several weeks to get something working, now one can get something like devstack up and running in under a few hours.

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

Everyone in the #openstack-infra for helping make OpenStack development work at a massive scale.  With 290 contributors and 2,288 commits in June alone, keeping everything running efficiently is a huge accomplishment.

3. How do you think the OpenStack community will need to evolve over the next few years in light of the fast growth and maturing user needs?

I would like to see more people focus on making sure OpenStack is stable, scalable and robust.  As a technical contributor I would like to see OpenStack become so widely used and mature that no one thinks twice about using it, similar to electricity, cars, the Linux kernel, and MySQL.

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

As a nova-core I spend more time than I care to admit doing code review, and use my email as a review queue.  I recently wrote a script to help keep my queue up to date by marking unread emails for recently merged gerrit patches as read.

5. What is your biggest hope for the OpenStack community in the next 5 years? What would be really, really amazing?

I hope to see all the OpenStack cloud providers succeed and continue contributing back to the community. This will validate OpenStack based clouds as a business model.

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.  

Everett Toews is a Developer Advocate at Rackspace making OpenStack and the Rackspace Cloud easy to use for developers and operators. Sometimes developer, sometimes advocate, and sometimes operator. He’s a committer on jclouds and co-author of the OpenStack Operations Guide. In the past he’s built web applications, taught workshops, given presentations around the world, and deployed OpenStack in production. Follow him on Twitter @everett_toews.

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

DevStack. I’m a big fan of DevStack at devstack.org. If you’re an application developer, it’s great for getting to know the OpenStack API. If you’re an operator, it’s great for learning how to deploy OpenStack and how all of the different projects fit together. If you’re an OpenStack developer, it’s great for contributing a feature or fixing a bug.

You can run it in a virtual machine on your laptop. You can run it in a server in the cloud. You can run it with a goat or in a boat. I’ve found it so useful I’ve blogged about it a number of times at blog.phymata.com.

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

Application developers. The developers who are building solutions on top of OpenStack. The ones who come to our mailing lists, IRC channels, and ask.openstack.org looking for answers on how to use OpenStack. IMHO, these people are our true users and an integral part of the community. They’re the ones who have to make all of OpenStack’s projects work together as a cohesive whole in their application architectures. They’re the ones who suffer the consequences (good or bad) of all of the design decisions made in the creation of OpenStack.

If we do our job right, application developers will demand to work on OpenStack clouds because they’re easy to use, reliable, and performant.

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

Tools. We need the existing and yet-to-be cloud focused tools to work well with OpenStack. For example: software development kits in many programming languages, graphical user interfaces, software configuration management tools, command line interfaces, etc. That means we as a community need to reach out to the developers of these tools, show them why OpenStack is important, and how to use it.

It would be amazing to see all of the contributing companies devoting developers to the open source tools ecosystem around OpenStack. These are the tools that will make application developers ecstatic and drive OpenStack adoption.

4. What other open source projects do you think work well with OpenStack, and why?

Software development kits (SDKs). Any of the ones listed at wiki.openstack.org/wiki/SDKs. When application developers talk to OpenStack they need to talk to its HTTP API. But the majority of application developers are not going to want to do that. They want to talk to OpenStack in the programming language of their choice. That means using an SDK.

But SDKs are just the start. Once you have those in place you can build higher-level tools on top of them. For instance, the Ruby fog SDK powers the cloud provisioning modules in Puppet and Chef.

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

I’m from Canada so I bleed hockey. I prefer to play it rather than watch it so sometimes that’s quite literal. On a related topic, I have a taste for strong beer or a strong taste for beer. When I’m not on the ice, I like to stay under water while scuba diving.

Also, comics. I like to obsess over my collection and ferret out back issues. I just finished Alan Moore’s run on The Swamp Thing. “We thought that the swamp thing was Alec Holland, somehow transformed in to a plant. It wasn’t. It was a plant that thought it was Alec Holland.” Great stuff.

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.  

Doug Hellmann is currently a Senior Developer with New Dream Network, LLC (DreamHost). He is a core contributor to the Ceilometer, Oslo, unified command line client, and requirements projects within OpenStack, and has contributed to many other components with code reviews and patches. Doug has been programming in Python since version 1.4, and has worked on a variety of Unix and non-Unix platforms for projects in fields such as mapping, medical news publishing, banking, and data center automation. He is a member of the Python Software Foundation, and served as its Communications Director from 2010-2012. After a year as a regular columnist for Python Magazine, he served as Editor-in-Chief from 2008-2009. Between 2007 and 2011, Doug published the popular “Python Module of the Week” series on his blog, and that material served as the basis for his book “The Python Standard Library By Example”. He lives in Athens, Georgia with his wife and two cats. His twitter handle is @doughellmann

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

I have a couple of other projects that I’m working on in my spare time. I find switching to something with a smaller scope can be a good way to clear my head at the end of the week. My favorite ways to unwind are to relax out on the patio with my wife and a glass of wine, or sit down inside with a good book.

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

The translation team is providing an important service that mostly goes unremarked. I was impressed when they came to the ceilometer team with patches to set up the tool chain and then started working on the message catalog without us having to even ask for help.

I just returned from a two-day intensive boot camp to learn about the work being done by the infrastructure team. I’m not sure most of the people involved in OpenStack realize how much effort goes into making the automated testing and code management systems work so smoothly. Any development team in the world would love to have access to the tooling they have put together for managing our processes and environment – and they do, because it’s all being managed out in the open.

3. Are there any skills that you think are critical for OpenStack developers in the next 5 years? What specialties will be most useful? Valuable?

Technologies change, and so do the specialties associated with them. The most important skills are the ones that carry over from one technology to the next. For example, it is important for a developer to be able to establish clean separation between the levels of abstraction in a design. Get that right, and aspects like testability, flexibility, and ease of maintenance will follow.

Communication is an equally important skill. The OpenStack community is large and diverse, with different groups working on aspects of the system that are interesting or important to them. Being able to explain requirements and plans clearly makes collaboration and coordination easier, and helps avoid misunderstandings or conflicts that can block progress.

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

I am a part of the team that created Ceilometer, the tool for measuring cloud usage. The initial goal was to create a system for metering that could feed data to a billing system. Since the first release, the project has grown a bit to cover monitoring, which shares some characteristics with metering but is different in several important ways. The response to the grizzly release has been overwhelmingly positive, so although we still have a lot of work to do we are already making users happy.

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

Our development process drives the success of OpenStack by making sure we are meeting real needs. Being open lets us take patches from all contributors neutrally, so users have choices in terms of vendors and deployment strategies. Being community-driven means that we accept patches that represent new features users want or fixes for bugs they have found by using OpenStack. The feedback loop encouraged by the open process we use ensures that we maintain good communication between users and developers – unlike some situations where new versions of a product are “thrown over the wall” without regard to user needs.