Support: 1-800-961-4454
1-800-961-2888

Understanding OpenStack Designated Code Sections – Three Critical Questions

After nearly a year of discussion, the OpenStack board launched the DefCore process with 10 principles that set us on path towards a validated interoperability standard. We created the concept of “designated sections” to address concerns that using API tests to determine core would undermine commercial and community investment in a working, shared upstream implementation.

Designated sections provides the “you must include this” part of the core definition. Having common code as part of core is a central part of how DefCore is driving OpenStack operability.

So, why do we need this?

From our very formation, OpenStack has valued implementation over specification; consequently, there is a fairly strong community bias to ensure contributions are upstreamed. This bias is codified into the very structure of the GNU General Public License (GPL) but intentionally missing in the Apache Public License (APL v2) that OpenStack follows. The choice of Apache2 was important for OpenStack to attract commercial interests, who often consider GPL a “poison pill” because of the upstream requirements.

Nothing in the Apache license requires consumers of the code to share their changes; however, the OpenStack Foundation does have control of how the OpenStack™ brand is used. Thus it’s possible for someone to fork and reuse OpenStack code without permission, but they cannot called it “OpenStack” code. This restriction only has strength if the OpenStack brand has value (protecting that value is the primary duty of the Foundation).

This intersection between License and Brand is the essence of why the Board has created the DefCore process.

Ok, how are we going to pick the designated code?

Figuring out which code should be designated is highly project specific and ultimately subjective; however, it’s also important to the community that we have a consistent and predictable strategy. While the work falls to the project technical leads (with ratification by the Technical Committee), the DefCore and Technical committees worked together to define a set of principles to guide the selection.

This Technical Committee resolution formally approves the general selection principles for “designated sections” of code, as part of the DefCore effort. We’ve taken the liberty to create a graphical representation (above) that visualizes this table using white for designated and black for non-designated sections. We’ve also included the DefCore principle of having an official “reference implementation.”

Here is the text from the resolution presented as a table:

The resolution includes the expectation that “code that is not clearly designated is assumed to be designated unless determined otherwise. The default assumption will be to consider code designated.”

This definition is a starting point. Our next step is to apply these rules to projects and make sure that they provide meaningful results.

Wow, isn’t that a lot of code?

Not really.  It’s important to remember that designated sections alone do not define core: the must-pass tests are also a critical component. Consequently, designated code in projects that do not have must-pass tests is not actually required for OpenStack licensed implementation.

About the Author

This is a post written and contributed by Rob Hirschfeld, Michael Still and Joshua McKenty.

Rob Hirschfeld sits on the OpenStack Board and is co-chair of the Core Definition Committed (DefCore). He has been involved in cloud for over 14 years and launched some of the earliest cloud companies. His educational background (Duke and LSU) is in computer science and systems engineering with a focus on distributed systems. He has always found deployment to be vitally important in developments - that lead him to found a SaaS start-up in 1999 and had made him a DevOps advocate. In addition to core cloud technologies, he is an Agile/Lean/TDD process evangelist who strongly believes that how you build and deliver is just as important as what you deliver. Professionally, he is a Sr Distinguished Engineer at Dell leading its OpenStack Cloud project.

Michael Still is a Nova and Oslo core reviewer at Rackspace, where he works on the Open Source OpenStack project as part of the Private Cloud team. He spends most of his time hacking on the libvirt virtualization layer in nova. Before joining Rackspace in 2012, Michael spent six years as a Site Reliability Engineer at Google and one year as an Operations Engineer at Canonical. In both roles, he was responsible for maintaining and improving web systems with millions of users.

Joshua McKenty is CEO and co-founder of Piston Cloud Computing. The first public release of OpenStack source code was on his blog, in May of 2010. But he spent the two years prior to that working on it, as the Chief Architect and Technical Lead of a project called NASA Nebula. He is currently on both the OpenStack Foundation board, and the Cloud Foundry Community Advisory Board. He co-chairs the OpenStack interoperability committee, and chairs the Transparency Working Group. He also serves on the finance committee, the compensation committee, and the program committees of every OpenStack summit to date. He was the official Gold Member" representative to the drafting committee, responsible for development of the OpenStack foundation bylaws. And in the early days, he was one of the four original members of the OpenStack Project Oversight Committee. Essentially, he's spent a majority of his time mucking about in OpenStack governance since the days we called this thing "Pinet." When he's not drinking coffee and eating donuts, he does a lot of public speaking and evangelism of OpenStack, particularly around its use in Enterprise private cloud settings. (He believes he's given over 28 speeches in the past year). His "day job" is as CTO for Piston Cloud Computing, the makers of the first commercial OpenStack software product.


More
Racker Powered
©2014 Rackspace, US Inc.