In the strange and sometimes ridiculous parlance that technologists have created for themselves, a stack is a collection of technologies that interoperate with one another to provide a platform for running services and applications.
One of the more common stacks for running Web servers, for example, is LAMP — the unofficial coalescence of Linux, the Apache Web server, the MySQL database manager and the PHP language. LAMP came together out of necessity more than by design.
The original OpenStack was a stack of two core components: one called Nova that pooled together computing resources, and Swift that pooled storage.
This led Wikipedia to define OpenStack as a provider of Infrastructure-as-a-Service (IaaS) — and for much of the press that relies upon Wikipedia for its sense of reality to persist in defining it this way.
Today, the number of components in the OpenStack stack is 25.
And this has led even some of the platform’s most vocal advocates to start wondering: If the whole idea of openness in the platform is to maintain interoperability, then by any chance, is OpenStack working against itself by forcing software and applications to support so many specific, pre-determined components?
On the other hand, since IBM, Oracle, VMware, HP, Red Hat, SUSE and vendors of that ilk are not only offering their own commercial implementations of OpenStack but are working to differentiate them as well, how much differentiation can one stack take before it technically ceases to be something that software purporting to support OpenStack will even recognize?
“With DefCore, one of the first things we worked on was a set of criteria to say, ‘What is it that is OpenStack?’” said Alan Clark, SUSE’s director of open source and industry standards, and also chairman of the OpenStack Foundation.
By “DefCore,” Clark is discussing an initiative begun by members of OpenStack’s Board of Directors last November to determine the minimum base requirements for any vendor’s implementation to be considered a legitimate OpenStack.
It’s important for a reason that may not be obvious: In the future, when you purchase server racks and storage networks for your data center from multiple sources for different applications, and they all purport to support OpenStack, you’ll want some assurances that they’ll support each other.
“We realize that we can’t name a whole component,” Clark told CMSWire in an interview. By that, he meant that as OpenStack has evolved, it becomes less useful to the multitude of developers who actually make its various components to declare any one such component — even Nova or Swift — a de facto part of the stack.
“We learned to focus on the capabilities,” he continued. “It’s not a finite thing. DefCore is something that will continue to grow over time. We started very small, and we’ll continue to grow and expand. So as the number of components continues to grow and increase, and the capabilities of those components meet the criteria, we will add those to the DefCore definition.”
It’s the same problem that Microsoft faced a decade ago, as it tried to take the next technological step with Windows but needed its hardware supports to get together on the same page. At first, the company published a minimum compliance list, which hardware partners largely rejected as too dictatorial. But when it attempted a compromise approach that subdivided operating system compliance into tiers, consumers sued, triggering the first course change in Microsoft’s operating system support policy that has led all the way to the production of Windows 10.
This time, OpenStack’s leaders need to draw the line somewhere.
But they’re very conscious of the role they would assume for themselves by acting as “OpenStack’s leaders.” What Alan Clark is advocating is for DefCore not to define the base specifications for what OpenStack is, but rather what it does.
“It’s not a closed, finite definition that will last forever,” stated Clark. “It’s one that is living and growing.”
'Living and Growing'
DefCore will not serve as some kind of minimum OpenStack, or a baseline reference implementation, Clark told us.
Instead, it will be a continuously renewed and refreshed agreement among the DefCore committee’s members as to which types and levels of interoperability the stack must provide, in order to qualify for certification.
And like the vendors’ “logo programs” of the past, this certification will allow members to bear a seal, said Clark, officially representing themselves to customers as being capable of offering the required degree of interoperability.
For each capability, he explained, there will be a battery of tests that vendors will take within their own laboratories, submitting the results to the OpenStack Foundation. Passing those tests will give vendors the right to bear OpenStack’s trademark and certification seal.
“In fact, one of the criteria we have in DefCore is that it’s adopted and being used by our user base,” he continued. “So we’re expecting to have new and innovative things.”
At the last OpenStack Summit, it was announced that federated identity will become part of the latest OpenStack “Kilo” release.
As of now, however, it is not part of DefCore. But Clark sees it likely that, over time, as enough members of the user base adopt Kilo’s functionality, it may become adopted into DefCore.
“Just because something is not in DefCore doesn’t mean that it is not included with the code that gets released,” said Clark. “All we’re trying to convey with DefCore is what we’re calling the ‘core pieces’ that we want people to depend on to be there from release to release going forward.”