Quick Primer on OpenStack DefCore


Recently, I've been getting a lot of questions from OpenStack community members around DefCore. So, I thought I would share some of the questions and answers broadly to help encourage the socialization of the plans and progress that has been made over the last year. We have started getting into enough detail that more people can provide constructuve feedback for the entire process.

For those who may not be familiar, OpenStack DefCore is a process being run by the OpenStack Foundation Board of Directors to define how we determine what “OpenStack core” is and how people determine if they can brand their cloud deployment as “OpenStack.” This effort spun up about a year ago and has made enough progress that we are starting to bring the details out into the broader OpenStack community for further discussion and comment. DefCore is often used to describe both the board subcommittee and the process we are following. I will generally use it to refer to the process.

I am a member of the DefCore subcommittee which is co-chaired by Rob Hirschfeld and Josh McKenty. You can find more details about the committee and our processes here:


If you want to know more about the history and how we got here, I would recommend catching up on Rob’s blog posts. He has done an admirable job of capturing and publishing periodic updates about the process over the last year. You can find relevant posts here:


If I haven't lost you yet and you are just looking for a quick update, I'll attempt a brief summary of the DefCore process and some FAQs.

  1. “core” will be defined by identifying a number of “must-pass” Tempest tests and “designated sections” of OpenStack code that must be in a deployment
    1. “must-pass” Tempest tests are being defined by DefCore and will be approved by the Board of Directors
    2. “designated sections” are being defined by the Technical Committee working with the PTLs. The TC has recently adopted a resolution on designated sections that can be found here: http://github.com/openstack/governance/blob/master/resolutions/20140402-defcore-designated-sections-guidelines
  2. There is a community project to build a tool (Refstack) that will run Tempest against a target OpenStack deployment and report the results and allow those results to be registered. It even includes a portable private-cloud oriented tool called "TCUP."
  3. If you’re OpenStack cloud passes the tests according to Refstack and you are using the “designated sections” of code - you can use the OpenStack brand!

That’s it! Of course, I’m sure that leaves tons of extra questions. I’ll take a stab at a few I anticipate but would encourage you to ask more. I'll work on adding to this FAQ as I get more questions from around the community. Here are a few that I've covered with folks recently.

Q. How are “must-pass” tests selected?

A. Ultimately, must-pass tests will be selected and voted on by the OpenStack Foundation Board. To make the process easier, we have done the following analysis:

  1. Grouped tempest tests based on ~70 capabilities. These are things like “compute-flavors”, “images”, “security groups”, “flavors” etc.
  2. Scored each capability based on important criteria detailed here: http://robhirschfeld.com/2014/01/07/defcore-critieria/
  3. Select the must-pass tests based on the scorin matrix and the judgement of the board

We are working on the first iteration of the scoring matrix based on OpenStack Havana. You can review the current draft here: https://docs.google.com/spreadsheet/ccc?key=0Av62KoL8f9kAdFo4V1ZLUFM0OHlrRnFpQUkxSHJ5QWc&usp=drive_web#gid=6

Q. How does the core definition change over time?

A. Our goal is to start with a very small core that is unlikely to have thing removed over the long haul. Then, we will add to that base with each integrated release as capabilities begin to become more commonly used, well documented and strategic to the overall direction of OpenStack. We are using the first pass, based on the Havana release, as almost a “practice test” for this new process. Our release of the Havana based core definition should happen at the ATL summit. We then plan on doing a revision of core based on Icehouse about 90 days after the summit. We want to release a Juno based core definition at the Paris summit. After that, we would expect to update the core definition coincident with each 6 month integrated release.

Q. Tell me more about Refstack. What does the project give us?

A. The Refstack project team is working on tools and website that automates the running of tests and reporting of results. One essential tool is called TCUP. TCUP provides a simple way to run the tempest tests in a Docker container on almost any system. The goal is to make it as simple as possible for DefCore reports to be gathered and reported widely for all kinds of OpenStack deployments. The results of any test run can optionally then be uploaded to a repository on the Refstack site. There will eventially be options for marking results public, managing who can submit official and unofficial results for OpenStack deployments/offerings, etc.

Q. I've seen several references to gathering input from the community. How does that work?

A. The Refstack effort will enable community input in a variety of ways. First, results submitted from TCUP runs will provide a lot of information about how broadly OpenStack capabilities are deployed over time. It will also provide the capability to provide feedback on what capabilities the community ranks highly or may be missing from the initial passes. This will provide a data-driven way for the community to drive further refinement and iteration of the DefCore process. As always, the DefCore meeting minutes are open and our mailing list allow broad participation in the discussions.

Q. How will enforcement work? is there a grace period?

A. While we have not nailed down all the details, we do anticipate giving operators and vendors plenty of time to get in line with the new definitions. Toward that end, our expectation is that nothing will be “enforceable” until at least the Paris summit timeframe. The time between now and then should allow for extensive community comment/revision and for appropriate adjustments to be made. Hopefully, the new core definition can be in effect by the end the year.

Q. How will you know if people are actually running the “designated sections” of code? Is there an audit?

A. At this time, we will be working on the honor system. We expect community members to respect the trust across members and comply with the requirements. If that proves to be insufficient, we probably have larger community issues to address.

Q. Why have the “designated sections”? Isn’t API compatibility sufficient?

A. The board and many community members felt that running substantive sections of the project was a requirement that would require all people using the OpenStack brand to stay involved in the projects. We felt this is essential to maintaining the kind of community that we see as important to the long term stability of the OpenStack project.

Q: Will there be a way for companies to run an API compatible OpenStack? will there be a separate mark?

A: We are not precluding that but it is not the focus of the DefCore project to work on that aspect of branding at this time.

Q: Why do we need any of this? why change things at all?

A: There are two primary drivers. First, we need a concrete answer to “What is OpenStack?” The most important asset of the OpenStack foundation is the brand. If we don’t move to put some specific criteria around the use of that brand, the foundation is at risk of devaluing this most important asset. So, we feel this project is essential to the future of the OpenStack Foundation. Second, we need an ecosystem where OpenStack deployments offer some promise of compatibility and interoperability. While DefCore will not completely solve all of the interoperability issues, it is a necessary and essential step in the process.

Q: What happens to individual projects like Swift, Nova or Heat?

A: Individual projects aren’t directly impacted by these changes. There will still be individual projects that can use the OpenStack brand such as OpenStack Compute, OpenStack Object Storage, OpenStack Networking etc. We are sorting out the exact requirements for determining how a project moves into a position to use the branded name. The goal of this project is to look at the standalone use of OpenStack in regards to broad cloud functionality.

Comments powered by Disqus

Contents © 2014 Troy Toman - Powered by Nikola