Because “cloud” means different things to different people, and because OpenStack tries to be all those things, individual OpenStack deployments can look very different from one another depending on many criteria. The “big tent” conversation, which has been ongoing in the OpenStack community for some time, strives to provide all of the answers for all of OpenStack’s large audience.

In this interview, we hear from the two people best qualified to talk about the OpenStack Big Tent. Thierry Carrez is director of engineering at the OpenStack Foundation, chair of the Technical Committee and Release Manager for OpenStack. Doug Hellmann is the current PTL (Project Technical Lead) for the Release Cycle Management project at OpenStack. Together, they will be presenting at the upcoming OpenStack Summit in Tokyo about how the Big Tent conversation has changed the release management process.

Thierry and Doug were kind enough to answer a few of my questions and give a bit of a preview of that presentation.

I know Thierry has covered this before, but can you give a quick overview of what the Big Tent means and where the metaphor comes from?

Thierry Carrez (TC): The term was first coined by Monty Taylor in this blog post. The post was part of a series that various community members posted while we were brainstorming ways to include new projects in our community while not losing our focus and not driving horizontal cross-project teams crazy. The idea behind the term was to push the idea of being more open, more welcoming, and having more room inside.

Doug Hellmann (DH): The main shift is from thinking of OpenStack as a collection of features to considering it a collection of contributors. Being “one of us” means collaborating and working using common tools and patterns, and if you are one of us your project can be part of diverse group of projects being built by other community members.

What interesting new projects are now on stage in the Liberty release due to this new way of looking at “What Is OpenStack?”

TC: We have services that were in the “incubated” state in the previous model, like Manila, Zaqar, Designate, or Barbican. We have long-standing members of our community that never tried to be part of the old integrated release concept, like Murano, Mistral, Congress, CloudKitty, or Solum. And we have new experimental services, like Cue or SearchLight.

At the last OpenStack Summit, the list of tags was still very sparse. What are the most important additions to this, and where can we find the full list?

TC: The full list lives here. Some important tags that we defined during this cycle touch on the affiliation diversity of the project teams (team:diverse-affiliation). Another important and very recent addition aims to describe which projects assert that they will follow a specific process in case they deprecate features in the future (assert:follows-standard-deprecation).

DH: We’re also starting to add tags indicating which projects are interacting with cross project teams directly. We have release:managed for the release team and vulnerability:managed for the security team, for example. There are tags in review now to describe how a project interfaces with devstack, as well.

What’s the progress on the tag explorer mentioned in Vancouver?

TC: The “software” section of the OpenStack website is being overhauled to present more projects in more details, including displaying relevant tags and other project metadata. This should be ready in the coming days.

DH: It turns out to be challenging to describe some of the criteria objectively when we look at them individually. I tend to fall on the side of encouraging more verbose documentation since it’s easier to cover nuanced situations that way, though I do see the benefit in some of the tags as badges to encourage projects to step up their game, so to speak.

In Vancouver, it felt like you had thought of everything. What have the surprises been in tags, projects, and other things that you didn’t anticipate?

TC: Personally I thought we’d define a lot more tags in six months. I don’t feel like we have covered the scope of all the different meanings the “integrated release” ended up describing in the old model. There is tension between what should simply be better documentation, and what needs to be codified as project metadata like tags.

What is a release? When I go to OpenStack.org and look for downloads, there aren’t any. What is the artifact that your release process produces?

TC: A release is a signed source code tarball. It’s a snapshot of our work at a given time. It is also the beginning of a stable branch series of point releases: we backport significant and safe fixes to that branch and make point releases that you can easily upgrade to. That said, a lot of distributions take that source code tarball and package it inside a packaging system for easier consumption and installation by operators. So in a sense, the release also marks the end of the upstream work and the start of the downstream work.

DH: You’re right that there is no single downloadable artifact on OpenStack.org. We create a separate tarball for each component, and deployers can combine those to create a cloud with the features they want.

What does a “release” look like, now that there’s no integrated release? Will there be several releases based on various tags or combinations of tags? Or will there be no release at all?

TC: The “release” becomes more intimately tied to the concept of stable branch, I think. All projects in the “release” maintain a stable branch that is roughly created at the same time (at the end of the Liberty development cycle). All of those are tested together in integration testing. We agree that it can be confusing to see what is “in” a release, especially as we abandoned synchronized versioning. This is why we worked on a website to show which versions and which artifacts are part of the same release series. You can find it at http://docs.openstack.org/releases/.

DH: Exactly. Although no software is ever truly finished, the stable branches represent a point in time when the feature set and stability represent a version of the project that its contributor community has declared willingness to support.

OpenStack Summit
Speaker Interview

This article is part of the Speaker Interview Series for OpenStack Summit Tokyo, a four-day conference for developers, users, and administrators of OpenStack cloud software.