Get the highlights in your inbox every week.
Interview with Doug Hellmann with OpenStack
Bridging the gap between OpenStack and Python
Consistency—a necessity when it comes to any large-scale, open source project. Sharing source code and libraries between the different components of OpenStack is critical to its rapid evolution and fast-paced development. The Oslo program is what holds it all together and brings consistency to OpenStack. We wanted to learn more about Oslo and what is does for OpenStack. So we asked the program lead to share his thoughts.
Meet Doug Hellmann. He is currently serving as the Program Technical Lead (PTL) for the Oslo program for the Icehouse release. Hellmann is a Senior Cloud Developer with DreamHost and a Python programmer who likes working on the Oslo program because it's helping to establish crossover between the OpenStack and Python communities.
We caught up with Doug to learn more about Oslo, how the different components of OpenStack interact with it, and what we can expect in the upcoming Icehouse release.
What does the OpenStack Common Library (Oslo) do for OpenStack?
The members of the Oslo program help the developers from the other OpenStack programs share source code. When a common aspect of the implementation of two projects is identified, we help prepare the source code and organize it in a way that makes it easy to reuse. We also provide general advice about coding techniques and existing Python open source libraries.
Why is Oslo important to OpenStack? And how do the different components interact with Oslo?
The Oslo program brings consistency to OpenStack. Before Oslo started, some of the OpenStack projects were already sharing source code by copying it between repositories. This resulted in slightly different implementations in the different copies. Under Oslo, code like that has been moved into an "incubator" to give a common origin for copies and prepare to move the source into libraries. The incubator reduces the chance that the code will change between projects, and publishing the incubated code as libraries provides a single copy of the source code while still allowing sharing.
Using libraries to share code between projects gives us several benefits. It ensures that we have good test coverage, because the maintainers of the library are focused on testing the included source code, rather than the applications using it. Libraries also encourage developers to participate in more than one project within OpenStack, since they are already familiar with the tools being used. And most important, sharing source code through libraries means that deployers see consistent behavior between applications with new features and bug fixes, as well as little things like applications using the same configuration option names and file formats.
What are some of the major improvements the Oslo team is working on for the Icehouse release?
We've had three big successes in the Icehouse release.
- First, close to the end of the Havana cycle we released the code OpenStack uses to communicate internally as a library called oslo.messaging. For Icehouse, we have started to update applications to use the new library. That ongoing work is providing some important insight into the processes and tools we need to make similar adoptions go more quickly.
- Second, a lot of work has gone into preparing the database access code currently in the incubator to be released as a library, and we expect to finish that during the Juno cycle. The messaging and database libraries are the biggest and most commonly reused code bases in Oslo right now, so we are taking care to apply the lessons learned with the messaging library to the work on the database library. We introduced some changes that slowed us down during Icehouse, but they should make the transition during Juno go more smoothly.
- Finally, we have recently "adopted" several libraries that were created outside of the Oslo program, taking over management and introducing symmetric testing between the libraries and the OpenStack projects that use them, taking advantage of the same tools that run functional tests for the integrated OpenStack components.
What opportunities are there for folks interested in contributing to Oslo?
The OpenStack community has a strong culture of peer-reviewing code so, as with any other OpenStack project, the best way to become familiar with and start contributing to Oslo is to dive into code reviews for one of our repositories (see wiki.openstack.org/wiki/Oslo for a list). Reviewing patches gives you context for sifting through the collection of blueprints and bug reports, and having insight from new reviewers often exposes hidden assumptions existing developers have made in their code. Participating in our code review process is a truly important way to contribute.
Identifying opportunities for code reuse among projects is also important. The Oslo team is small, relative to the size of the overall community, and that community is producing a lot of source code. Finding patterns that suggest creating libraries often requires familiarity with multiple projects, and as the number of project grows we have to rely more on contributors to those projects to propose libraries themselves.
During Juno we plan to release several more libraries from the incubator, so if you have a special interest in a particular area of the source, in helping to manage those releases, or in updating projects to use those libraries, there will be plenty of opportunity to be assist with that work.
What excites you about working on Oslo and OpenStack?
The software we're building is obviously important, but the most exciting aspect of OpenStack is the people. From the very beginning of my involvement at the Folsom summit, the community has been extraordinarily welcoming and supportive. I attribute our fast growth in large part to that attitude, and the collaboration it produces.
I view the Oslo program as partly responsible for encouraging continued collaboration within OpenStack. We interact with most of the integrated projects as we do our work, and sometimes we need to negotiate changes to a library in order to make it useful to more than one project. Reminding everyone how the component they are working on fits into the overall project is an important aspect of that negotiation.
Oslo also provides opportunities to integrate the OpenStack and Python communities. As we review code in Oslo, we consider questions like whether we should create and maintain a new library instead of using something that already exists, and how to release the libraries we do create so that other projects can use them. I have been a member of the Python community for far longer than my involvement in OpenStack and until recently there was little cross-over between the two groups. That's changing, as we have started reaching out to authors of libraries and tools we use and as other developers find and use the libraries we release.
If you could name the next release of OpenStack, what would you call it?
Like a lot of people, I thought we were going to have a hard time coming up with names starting with K in Paris, but I see Av. Kléber and Rue Kepler are both fairly close to the area where the summit will be held.