OpenStack began with the mission to produce a ubiquitous open source cloud computing platform. A key component of that mission is building not only software, but a large OpenStack ecosystem that would support its growth and add value to the core technology platform. In carrying out that mission, the Foundation has been taking key steps to define the core technology platform and advance OpenStack interoperability.
The TL;DR summary: Now that we have tons of users, we need to make sure all (downstream) products labeled “OpenStack” have a certain set of core capabilities, and we need to verify those with automated tests just like we do upstream. End-users should be our focus, and ensuring they get what they want and expect out of the platform once it’s running as a service is paramount. The goal is to define the first set of tests in time for the May 2014 Summit in Atlanta. If this matters to you, get involved!
Read on to learn more about the rationale, history, future plans, and how you can get involved.
Why does interoperability matter for OpenStack?
We’ve heard from many users and operators that interoperability between OpenStack clouds and hybrid cloud scenarios are an important part of the value they are seeking. OpenStack is most useful when it provides a common platform to consistently deploy workloads between clouds without making resource intensive changes to operations tools and processes. Value is unlocked when development tools and applications have a common target across public and private OpenStack clouds.
The full potential of OpenStack will not be realized if users don’t know what they’re going to get from public cloud services or off-the-shelf distributions and appliances. Ambiguity or mistrust about the capabilities of OpenStack isn’t good for the business ecosystem or end users. It’s important that public clouds and private cloud products branded with OpenStack have a clear meaning in the market.
What is the Foundation doing?
One of the most important responsibilities we have as a Foundation is to ensure the long-term value of the OpenStack brand in the market. This has been an ongoing priority since our founding and has involved the collective effort of a great number of community members.
When we began, we implemented an OpenStack trademark policy, which allows broad use of the OpenStack logo and name for non-commercial community building efforts like user group meetups, while also creating special guidelines, technical requirements, and licenses for use by commercial products. As the community, the software, and the ecosystem have grown, so too has the need to refine these technical requirements for commercial products, by defining a core set of capabilities included in all products and services marketed as “OpenStack.”
It is indeed a large task, one that stems from the diversity of our community, the breadth of our ecosystem, and the broad application of our software. But it is one that will ensure the longevity, vitality and utility of OpenStack far into the future.
Therefore, in order to agree on a set of well-defined criteria for the core we must take special care to have a transparent and objective process. The Board of Directors and the Technical Committee have initiated a number of programs to tackle the issue.
IncUp (Early 2013)
The first step was forming the Incubation/Future of the Core (IncUp) committee, a joint effort between the OpenStack Board of Directors and Technical Committee, aimed at tackling the process for expanding the scope of OpenStack through new project incubation and promotion.
At the April 2013 board meeting, the Board of Directors approved the IncUp committee’s recommendations, including 1) The technical committee continues to manage the incubation process for new projects applying to be part of the coordinated, integrated release 2) Projects that are part of the coordinated release should be referred to as “Integrated” (but not necessarily “Core”), and 3) “Core” is a label the Board can attach to a project that is part of the regular integrated release.
The Technical Committee is following on these efforts by creating a clear set of guidelines for projects that wish to be officially incubated, as well as the attributes an incubated project should have before being approved for graduation to the integrated release. The purpose of the guidelines are to maintain a high standard of quality and cross-project integration for OpenStack.
The important outcome of the IncUp committee places the responsibility to manage the technical scope of the OpenStack project with the Technical Committee, while the Board ultimately sets the criteria for which technical capabilities should be present in (downstream) commercial products or services marketed as OpenStack. This led to the next phase in the process: considering how to define those criteria in a standard and broadly applicable manner.
Enter the “Spider” (2013)
The Board of Directors formed a new work group to tackle the task of determining how to define Core in a consistent manner that would apply to the varied set of use cases OpenStack addresses and the broad set of technology developed within the community. Early in this effort, the team, including Alan Clark and Rob Hirschfeld, drew a map on a whiteboard of dependencies and relationships that came into play when trying to define which projects were “Core OpenStack.” The drawing, which revealed some of the complexities of the task, resembled a spider mind map and inspired the nickname for the group.
Rather than jump straight into choosing specific projects that would qualify for the “Core” label, the committee focused on defining principles that would apply equally to any commonly required and deployed component of OpenStack deployments. These principles were drafted and reviewed through the summer and fall of 2013 at a series of open community meetings held online and in various locations. After several revisions, the Board of Directors approved the final principles at their November 2013 meeting.
DefCore (Ongoing)
After approving the guiding principles at the Hong Kong Summit in November 2013, the OpenStack Board of Directors created the DefCore committee, chaired by Rob Hirschfeld and Josh McKenty, to define a “core” set of capabilities which are expected to be present in all commercial products marketed as “OpenStack”, along with a set of tests to validate those capabilities.
The creation of DefCore marks a new focus on including a test-driven component to the definition of core. This route is more objective, and test-based standards better addresses our commitment to interoperability. The committee is working to determine which capabilities a commercial offering should include to make use of the OpenStack marks and is currently in the process of standardizing the tests that must be passed. The goal is to repurpose the same testing that we’ve been doing on the upstream code to apply to the products and services downstream, ensuring that they retain the fundamental building blocks of Openstack.
One of the realizations coming out of the early work of the committee was that users think in terms of “capabilities” more than “projects.” Projects are how we organize as a development community, but in the end the capabilities delivered by an openstack-powered cloud are what really matter, and in practice many capabilities rely on multiple underlying “projects”. This is a subtle but important distinction which is reflected in the way we think about writing tests to validate those capabilities in the downstream products licensing the OpenStack brand.
The DefCore committee is working against an aggressive timeline with a plan to the pilot must-pass tests for Havana before the OpenStack Summit in Atlanta in May. Icehouse will follow shortly thereafter, and Juno’s test will be ready to go by the Paris summit.
Being able to expose OpenStack cloud test results and provide a defined target for end users is an incredibly important effort and high priority for the Foundation this year. It is our hope that by outlining the steps we’re taking, the community will involve themselves in these efforts and track the progress of this vital endeavor. To get involved in the DefCore process, sign up for the mailing list and follow the wiki for updates.
Instant Poll:
Create your free online surveys with SurveyMonkey , the world’s leading questionnaire tool.
the OpenStack team at Cisco. Although new to OpenStack (started in 2013), Paul has been a software developer for over 30 years working at various companies and industries. His current focus is on VPNaaS, and he has been trying to drink from the fire hose for all things Neutron. An empty-nester, he lives in New Hampshire, USA, with his wife and pets. Outside of work, Paul enjoys photography, playing soccer and volleyball, watching sci-fi and action movies on his home theater, and playing on the skid pad with his BMW. Follow him on Twitter @pmichali
