Talk by Mark Voelker and Chris Hoge at the OpenStack Newton Design Summit in April 2016. In this talk, we describe why interoperability for OpenStack clouds matters, what some of the major pain points are when trying to write a cross-cloud app, and what's being done to make those problems a thing of the past. We'll also discuss DefCore's role in shedding light on the problems and creating strong feedback loops..
Interoperability: The Elephants in the Room & What We're Doing About Them
The Elephants in the
Room & What We're
Doing About Them
Chris Hoge, OpenStack Foundation
Mark T. Voelker, VMware
A (Very) Brief Intro To DefCore
• September 2012, Foundation bylaws required a “Faithful
Implementation Test Suite” to ensure “compatibility and
interoperability” for products.
• DefCore working group was founded in Fall of 2013 to fulfill the
• 1st guideline approved in Winter of 2014
– Placed into effect in Spring 2015
• 5 Guidelines since then (newest: 2015.07, 2016.01)
• Guidelines consist of:
– Components: A product, in this case Compute, Storage, or a
– Capabilities: defined by a grouping of tests, and chosen
against a set of 12 criteria
– Designated Sections: upstream code that must be running,
determined by the working group in collaboration with the
technical leaders of the projects.
• Good news! OpenStack is rich and extremely flexible!
• Bad news! OpenStack is rich and extremely flexible!
• Lots of ways to configure things
• In same cases, more than one way to do things
• Policy isn’t discoverable
• Rapid release cadence = products built on many
versions are in production
• What does [$myfav_sdk | $myfav_tool | $myfav_app]
actually support vs what’s actually in the clouds I might
want to use?
• Why does Shade have to exist?
Some of the Biggest Challenges
• Image operations
• Networking (particularly external connectivity)
• Policy and configuration discovery
• API iteration vs tool/SDK release cadence
– Also, different approaches to API lifecycle among projects...some
projects are still on v1, others are on v3, some adopting microversions,
some not yet
– Implicit test requirements
– Finding good data on what’s widely used
• Project documentation:
– Are Zones ok in Nova?
– Is it ok to expose Glance v1 to end users?
– Is Keystone v2 really “SUPPORTED” or is it really unmaintained?
Some of the Biggest Challenges Today
– Image formats
– What does a cloud provide, and how?
• Lack of awareness about how DefCore:
– Among devs: how should interop influence
– Among consumers: what DefCore means for them
• Mapping of capabilities to APIs and how it should
guide application development.
What We’re Doing About It
• We exist! By forcing a measurable standard, we can find
the problems in that standard and iterate to improve it.
• Working with vendors to understand the challenges of
• Working with developers to improve the upstream APIs
and usage models.
• Working with QA to improve testing.
• Collaborating with the technical community to identify
key issues that real clouds, both public and private, face.
• Providing meaning for the OpenStack logo when it
appears on a commercial product.
DefCore Is Helping Make
• Awareness is half the battle
• Examples of outcomes or discussions in progress:
– Nova/Glance image proxy discussions and potential
– Consolidation and discovery for image upload APIs
– Keystone v2 API deprecation
– Glance v1 API deprecation
– get-me-a-network in Neutron
– TC/Nova passing resolution clarifying intent of Nova
drivers for product builders
What’s New In DefCore
• Networking capabilities are advisory, moving to
required later this year
• Keystone v2 being dropped due to deprecation,
more focus on adding v3 capabilities
• Refstack.openstack.org becoming the clearinghouse
for test info
• Ability to run tests via tempest plugin interface ==
expanded possibilities for Swift, Heat, etc.
• Moving beyond the Nova proxies to direct API calls
for images, storage, and networking.
What’s DefCore Doing Next?
• Coming soon: DefCore report on top interop issues
– Periodically updated so we can measure progress on big barriers
– Intended to drive conversation and accountability
• More work on tests
– Drafting interoperabiliy test spec to help technical contributors
understand what makes a good interoperability test
– Working with QA community to reduce unnecessary admin
• Beginning discussion of vertical interop Guidelines
– E.g. for use cases like NFV where requirements may be a bit
different than general purpose compute clouds
• Other stuff?
• OpenStack Interop Homepage
• DefCore Wiki
• An Introduction to DefCore (“The
Doctor Who Deck”)
• DefCore Committee Mailing List
• #openstack-defcore on IRC
• DefCore Git Repository
• Tempest Configuration Guide
What Do You Think The Issues Are?
• Submit your test results to RefStack!
• Add your two cents to this etherpad
• Come to the DefCore working session
(Thursday, 9:50am, Hilton Salon J)
• Talk to project team developers,
product companies, and other users
here in Austin
• Grab one of us this week or on IRC