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…
Leave a Reply