How I Contribute To OpenStack: Red Hat’s Mark McLoughlin

Filed in Product & Development by Andrew Hickey | August 7, 2012 5:00 pm

OpenStack[1] is the platform upon which Rackspace has built its open cloud[2]. The community-driven cloud operating system, which Rackspace co-founded, has sparked an open source cloud revolution. Enabling the community of hundreds of developers to contribute code and leverage the OpenStack cloud however they want has created a shift in how applications are developed. This blog series collects insight straight from key developers on the front lines about how they became involved in OpenStack and the open cloud, and what contributions they’ve made.

In this installment, Red Hat[3] Principal Software Engineer Mark McLoughlin discusses what drew him to OpenStack and open source and what he’s done to contribute to the open cloud.

Tell us about yourself.
I’m a 32-year-old Irishman, living by the sea in Dublin, Ireland and working remotely for Red Hat. I’ve been with Red Hat for eight years now, originally working on the GNOME desktop before working on all things virtualization – i.e. xen, kvm, qemu, libvirt and RHEV. Outside of work, I’m married to a tax lawyer and we have an 18-month-old daughter. I’m into the likes of sailboat racing, hiking and running.

Why did you become involved in OpenStack?
I had been watching OpenStack since it was first announced and was convinced that the project and its community were on track to make a massive impact in the cloud space. I saw OpenStack as an umbrella under which developers on independent projects work together on a regular release cycle — a large and diverse community of contributors; design and development done in the open, warts and all. All of these things give a project great strength and confidence that it will stick around to solve these big problems we’re tackling. In that sense, OpenStack looks an awful lot like the GNOME project that I’d known so well. I think it’s an excellent model for organizing a project. I was keen to be involved and help make it a success.

Given that Red Hat’s mission is all about being “the catalyst in communities of contributors” and that, technically, the project was well aligned with Red Hat, I felt that Red Hat really had no right not being involved with the project. Thankfully others at Red Hat felt the same way.

Tell us about your specific contributions to an OpenStack project (i.e. what the code was and what it did).
I’ve deliberately chosen to work on aspects of OpenStack that I felt were important to the long-term health of the project. These types of things are never very sexy, but I do feel they’ve been useful contributions. Out of the core projects, I’ve concentrated mostly on Nova [OpenStack Compute], fixing relatively small issues and reviewing patches in gerrit[4]. I try to put aside a good part of my time for patch review because it’s very important that peoples’ contributions are both appreciated and reviewed thoroughly.

I guess my biggest single contribution to date is the cfg module[5], which brings together command line parsing and config file parsing. The idea here was that there was a divergence between core projects on how to handle configuration options and we would greatly benefit from sharing common code and patterns between the projects. I remember — at the Essex Design Summit — Vish [Ishaya, former OpenStack Compute Project Technical Lead] talking about this issue and basically warning people away from it in the short term because it was going to be especially painful to sort out. I guess I took that to mean it would be an interesting challenge and just dug into it. In the end, coding the cfg module wasn’t such a big deal, but doing the work to get the core projects to adopt it (and adopt common usage idioms for it) turned out to be a long and protracted slog. However, the cfg module is only part of the openstack-common[6] effort which Jason Kölker [Rackspace OpenStack Developer] and I started early this year. We — and a bunch of others — have been gradually working to consolidate much of the code copied and pasted between core OpenStack projects into a common library. You can think of this as repaying some of the technical debt the project incurred in its early days.

Another effort I started was the maintenance of a stable branch and releasing of point releases in parallel with our development stream. The idea here is that OpenStack distributors and operators need a “safe source of fixes for high-impact, user-visible bugs.” I think this is really important for any successful project and it looks like many have appreciated the effort with the Diablo and Essex branches and the 2011.3.1 and 2012.1.1 releases.

How does OpenStack change your approach to cloud development?
OpenStack has really opened my eyes to a distinction that I previously would have been happy to see waved away. That is the distinction between data center virtualization and large scale, self-service, on-demand, pay-as-you-go cloud. The term “cloud” long ago lost any real meaning. Is it valid to call a virtualized   a cloud? Probably not. But how about if you put a self-service portal in front of it and maybe implement chargeback? That’s looking more like a valid cloud, but does it really have all the benefits people are seeing from the public cloud?

I’m now thinking in terms of a distinction between “Amazon-style cloud” (with apologies to our friends at Rackspace) and data center virtualization. In the former you typically run horizontally scalable, fault tolerant applications; whereas the latter is more concerned about legacy workloads which usually have serious high availability requirements. In the latter, policy-based live migration is a key requirement, whereas in the former it depends on the SLA vs. cost tradeoff you wish to make as a cloud provider.

I see one of the strengths of OpenStack as its focus on “Amazon-style cloud” and I hope — at least in the medium term — we maintain that focus and avoid chasing the data center virtualization space. We have a massive amount of work to do even on this more constrained problem, so the last thing we need to do is broaden the problem space we’re tackling. I thought Chris Kemp [NASA developer, OpenStack co-founder and CEO and founder of Nebula Inc.] did a great job of making this point during his keynote at the Folsom Design Summit. He basically implored the community to not go after the VMware space.

What are some of the benefits of an open collaboration effort among so many companies sharing open source code, like OpenStack?
Wow, what a question.

I first had exposure to open development many moons ago as an intern at Intel where a mentor introduced me to what was going on in the Linux kernel community. I was truly overwhelmed by the level and diversity of the activity going on. All these cool people from all over the world, from lots of different companies or no company at all, were building this massively complex piece of software bit-by-bit and, apparently, doing an excellent job of it. That model made immediate sense to me, but it’s difficult to put into words exactly why.

Software development sucks. I think we’re all conscious that we must be in some sort of Stone Age of software development. Given the complexity, and the tools we have for dealing with that complexity, the fact that these systems we’re building work at all is a miracle. Some people have traditionally chosen to address that with massive amounts of bureaucracy and process, with top-down design done upfront and strict control by a phalanx of managers.

That traditional model has produced some great technology but it’s costly, doesn’t guarantee success and certainly is no fun. You can see from the Agile movement that software developers know there is a better way. Open development is another attempt to “uncover better ways of developing software by doing it and helping others do it.” Indeed, if you compare the “Principles behind the Agile Manifesto[7]” to the values that many large, successful open source projects are built around, it’s very easy to see they have much in common.

All of this is a roundabout way of saying that open development is one proven model for building great technology. It’s a model where you put self-organizing teams in the driving seat, where you value craftsmanship, where you trade control for innovation and where the best ideas win.

Thank you, Mark, for your contributions to OpenStack and the open cloud.

Are you a developer contributing to OpenStack? We’d love to hear more about what you’re doing and why. Leave a comment here or contact me at andrew.hickey@rackspace.com[8]

Endnotes:
  1. OpenStack: http://www.openstack.org/
  2. open cloud: http://www.rackspace.com/cloud/
  3. Red Hat: http://www.redhat.com/
  4. gerrit: https://review.openstack.org/#/q/status:open,n,z
  5. cfg module: http://docs.openstack.org/developer/nova/api/nova.openstack.common.cfg.html
  6. openstack-common: https://launchpad.net/openstack-common/
  7. Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html
  8. andrew.hickey@rackspace.com: mailto:andrew.hickey@rackspace.com

Source URL: http://www.rackspace.com/blog/how-i-contribute-to-openstack-red-hats-mark-mcloughlin/