Interview with Thierry Carres, Chairman of the OpenStack Technical Committee and Release Manager

Original author: David M. Fishman
  • Transfer
We present the fourth of a series of interviews with technical managers of the OpenStack project on the Mirantis blog. Our goal is to educate the wider community of technical experts and help people understand how they can contribute to and benefit from the OpenStack project. Naturally, the following is the viewpoint of the interviewee, not Mirantis.

Below we present an interview with Thierry Carrez, Chairman of the OpenStack Technical Committee and Release Manager.

Mirantis: Tell us about yourself.

Thierry Carres: Of course! This year I turned 40 years old. I live with my wife and two children in a small village in the center of France.

Q: Very nice. Do you notice cultural differences among developers from around the world?

A: Yes, these differences are striking, and one of the tasks of the global community is to form a single whole that overcomes them. In addition, there are differences arising from the diversity of professional experience, so it is not only a matter of geography.

Q: Can you give an example? In Eastern Europe, for example, code reviews are perceived as criticism or disapproval - although in fact, these reviews are intended to help developers improve the code.

A: There are also problems with the perception of the “-1 ″ code score in Japan, for example. Also, developers who come from large companies are afraid to see their name indicated explicitly and constantly, next to a change in the code. This keeps them from fully participating in the developer community. For those developers who started in open source projects or in startups, transparency is not a problem, but an opportunity.

Q: What is your history of working with OpenStack? Why are you interested in participating in the project?

A: I was the technical project manager for Ubuntu Server at Canonical and worked on the Ubuntu Enterprise Cloud product. When creating OpenStack, I, along with several colleagues from Rackspace, helped organize the project and performed release management functions.

I am particularly interested in promoting a development model based on the principle of “open innovation”: creating a smooth technical work environment that allows developers across the industry to work together on the design and development of OpenStack. My goal in the project is to make sure that we adhere to this model, contribute to its support and development, and prove its success.

Q: How do companies adopt the “open innovation” development model?

A: When working on the principle of open innovation, companies hire developers to work on the project, but do not control the project itself. They direct the priorities and interests of developers within the project, implicitly, as intermediaries. But, in general, all project participants and leaders among them control the process themselves. Companies are forced to accept a situation where they must give up control in favor of influence.

Q: Many companies use OpenStack, but do not exchange experience. Does it need to be changed? If so, how? Or is this common practice in an open source project?

A: The Apache license allows companies to take the code and not contribute, so this is definitely a common practice. However, this is not a good idea. Without investing in a project, you significantly reduce your impact on the technical side. You also face the risk that new code and additional features violate your code recipe. In the end, it's not worth it.

Q: Who determines the principle of building OpenStack - how are decisions made?

A: Our feature development process is extremely open. Anyone can suggest a change, which is sent for review by our main employees who check the code. With that said (especially for destructive functions), you increase your chances of a successful test if you join the design and development mailing list and participate in our development seminars. In this way, the community can approve a function before it takes too much effort. The decision-making process is a compromise achieved with minimal effort between developers in a project. For each project, we have an elected technical project manager who can make the final decision, but this is required in very rare cases.

Q: What is your responsibility as chair of the technical committee and release manager?

A: The Technical Committee is the final expression of the technical meritocracy in OpenStack. Committee members are elected by participants in various projects. Its role is to consider new projects that are offered for development in OpenStack, and solve potential cross-project problems. As the chairman of the committee, I am responsible for keeping track of the issues for consideration by the committee, for launching IRC meetings and disseminating the outcome of these meetings to the rest of the community.

Release management has two aspects. The first one (obviously) is to coordinate the release of various OpenStack projects, but with the automation tools we have, it is very simple. Most of the release management work is managing six-month release cycles, tracking what is being done, and trying to prevent cross-project interference.

Q: Often people interested in OpenStack comment on the use of IRC. “Why are you using IRC? This is long outdated. Why don't you use Twitter like everyone else? ”

A: Hm. Not everyone wants to be tied to a proprietary messaging platform! I have been using IRC for the past 20 years and I think this is the perfect tool for quick online discussions and organizing meetings. We have channels dedicated to specific topics and channels of individual teams. This is a public space for communication, it works around the clock. We keep an action log, that is, the data does not disappear. We can also use proxies to connect. This is very widespread among developers who participate in our open source projects, and most of us use them outside of OpenStack.

Q: You mentioned six-month release cycles. What is their value?

A: The most obvious value of release cycles is to facilitate release. This helps us shift our focus from developing features to a bugfix of critical errors to a release, which improves the quality of the release. For me, the greatest value of release cycles is the creation of a rhythm of effort, a certain pulse, which is very important for our virtual and global community in terms of uniting in work on the same project.

Q: Can you describe the OpenStack release cycle, from brainstorming to implementation and integration?

A: We start with the Development Workshop, where developers who want to work on a specific project during the next cycle present their ideas and discuss them with other developers. Then the implementation begins, which is artificially divided into three brief “stages” to break down the work on the project.

After the third stage of development, we switch to the function freeze mode, in which the focus is shifted to correcting the list of critical errors before release. After all critical errors have been fixed, we create a release candidate. If it does not find errors critical for the release (in this case, we can correct them and rebuild the new release candidate), all candidates gather at the time of release to create the final integrated release of OpenStack projects.

Q: What determines the frequency of OpenStack releases?

A: We are trying to have a main branch always available for launch. Releases are really just points in time, tags in the repository that we mark as special cases. Our release cycle is designed to reduce the risk that a critical regression will infiltrate our “releases”, so “releases” carry less risk than accidental basic code fixing. What is interesting is what follows: we maintain stable branches, where we apply patches for critical bug fixes and vulnerability fixes, and these stable branches are created from release points.

The current OpenStack release frequency is a compromise between our desire to speed up iterations, the ability to conduct Developer Seminars, the need to update documentation after freezing functions, the frequency of freezing functions, and the availability of resources to support stable branches.

Q: What are the advantages and disadvantages of a three-month release cycle?

A: You may remember that at the beginning of the development of OpenStack we had a three-month development cycle. Now usually 4 weeks pass from the moment of stopping adding functions to receiving a working candidate release. With a six-month release cycle, it is possible to freeze functions for a month. In a three-month release cycle, this period is shorter. Release every three months means maintaining half the number of stable branches. Thus, if more people correct critical errors in the remaining period of the cycle (not during the period of freezing functions) and more people help maintain stable branches and security updates, we can definitely proceed to the three-month cycle. I like to host the Developer's Seminar at the beginning of each cycle (I think this helps us achieve better results), so I suppose

Q: How can developers participate if they are forced to skip a seminar or cannot afford a trip to the Developer Seminar?

A: Participation in the Developer Workshop is by no means a necessary condition for adding code to OpenStack. The discussion can be conducted on the mailing lists or in the code verification system. A developer workshop is a convenient way to get through the brainstorming and implementation stages faster, receiving early feedback from live personal discussions.

Q: Does the OpenStack community think about following the Ubuntu community with an online-only developer workshop? Will this work for OpenStack?

A: Ubuntu developer workshops have basically turned into feedback exercises where key developers present their work plan for the next few months. For these purposes, the virtual environment is ideal and saves a lot of money. OpenStack developer workshops are used for something else: motivating the global and virtual developer community for the next six months, brainstorming on development ideas, or reducing duplication of effort by talking to different development groups. But the most important reason to leave the personal communication of the participants is the preservation of common sense in the community. Personal meetings are necessary in order to resolve any conflicts that have accumulated over 6 months of virtual communication.

Q: Recently we interviewed Monty Taylor, technical project manager for continuous integration. Why do you think continuous integration is so important for OpenStack?

A: Continuous integration allows us to trust that the content of the main branch works and does not contain regression. OpenStack is a complex device and you can accidentally break it. Previously, I deployed the release locally and periodically ran several manual tests to make sure that the basic functionality was not broken.

Today’s infrastructure runs thousands of times more tests than I ran before, and so on for every proposed change. Continuous integration allows me to sleep peacefully. Without her, we would not be where we are now.

Q: Are there areas of the development process that are not yet automated, but will be automated in the future?

A: No, all aspects are automated, although there is room for improvement. Some projects might use more integration tests; your continuous integration is only as good as your tests.

Q: What should developers who want to be involved in writing code for OpenStack bring to the project?

A: A sense of humor. OpenStack developers are a community of nice people and would like it always to be this way!

Q: What advice would you give to beginners - those developers who want to contribute, and companies who want to build a business around OpenStack?

A: The OpenStack project is what we make of it. Join us, you won’t regret it!

Q: Thank you, Thierry!

A: Thanks!

Also popular now: