I’m excited to report about the OpenStack Board progress on defining OpenStack core. At the Hong Kong summit, Joshua McKenty and I were asked to chair a new standing committee, now known as DefCore, to define “OpenStack Core” based on the core principles that we determined over the last 6 months (aka “the spider”).
Joshua and I took on the challenge with gusto and I’m proud to say that we’ve already made significant progress against an aggressive timeline to have the pilot must-pass tests for Havana defined before the Juno Summit in April 2014. It’s important to remember that we’re moving from a project based definition of core to test-driven capabilities because this best addresses our interoperability objectives.
In the 8 weeks since the summit, we’ve had six very productive meetings (etherpads for Prep, DefCore.1, DefCore.2, Criteria 1 and 2) with detailed notes and recorded content. Here’s my summary of our results so far:
An Aggressive Timeline for having pilot Havana must-pass tests approved by the Juno summit in May 2014. That drives the schedule backward toward a preliminary list in March. Once we have a pilot list for Havana, we expect to have Ice House done +90 days and Juno done at the Paris summit.
Test Selection Criteria a preliminary set of 14 criteria (needs a stand alone post) that will be used to quantitatively score the current 700+ tests. We also agreed to use a max 100 point weighting system for the criteria. The weights and score requirement iteratively once we have done a first scoring pass. Our objective is to make must-pass test selection as objective and transparent as possible (post with details).
Distinction between Capability & Test is important because we recognize that individual tests may validate multiple capabilities and individual capabilities may have multiple tests. Our hope is to present the results in terms of capabilities not individual tests.
Holding Off on Bylaws Changes needed to clarify how OpenStack manage core definition. It was widely expected that the DefCore committee would have to make changes to the OpenStack bylaws; however, we believe we can proceed without rushing changes. We have an active subcommittee preparing changes in advance of the next DefCore cycle.
Program vs. Project Definition efforts are needed to help take pressure off requests to have “projects promoted to core status” and how the OpenStack trademark is used for projects. We are trying to clarify OpenStack Programs (e.g.: OpenStack™ Compute) carry to the trademark while OpenStack Projects (e.g.: Nova and Glace) are members of those programs and do not carry the OpenStack trademark directly. Consequently, we’d expect people to say “OpenStack Compute Project Nova” instead of “OpenStack Nova.” This approach addresses several issues that impact DefCore Board activities around trademark, core and brand.
RefStack Development and Use Cases provide the framework for community reporting of test results. We consider this infrastructure critical to getting community input about must-pass tests and also sharing interoperability information. This effort is just beginning and needs help from the community.
For all this progress, we are only starting! We’ve cleared the blocks preventing implementation and that will expose a new set issues to discuss. Look for us to start applying the criteria to tests in the next months. That will quickly expose the strengths and weaknesses of our criteria set. We’ve also got to make progress on Program vs. Project and start RefStack coding.
We want community participation! Please let us know what you think.