This document summarizes a presentation about interoperability between OpenStack and other open source infrastructure projects like Kubernetes. It discusses how the OpenStack Interoperability Working Group defines guidelines for compatibility between different OpenStack distributions. While no distribution will be identical, following these guidelines ensures core capabilities are supported across approved implementations. It encourages selecting technologies based on common interfaces like APIs, Terraform, or Kubernetes rather than any single vendor implementation to avoid lock-in and allow flexibility.

1. © 2014 VMware Inc. All rights reserved.
Interoperable Clouds and How to Build
(or Buy) Them
What’s up with interop in OpenStack, K8s, and more!
Mark T. Voelker
Oct. 24, 2017
All Things Open 2017

2. Mark T. Voelker (@marktvoelker)
• OpenStack Architect @ VMware, Interop Working Group co-chair, Triangle OpenStack Meetup co-founder,
OpenStack Foundation Member #54, OpenStack ATC, Ex-Puppet OpenStack core dev
• Fact: can be bribed with doughnuts
• In copious (hah!) spare time: OpenStack solutions, Big Data, Massively Scalable Data Centers, DevOps,
making sawdust with extreme prejudice, raising two great kids with my awesome wife in North Carolina
• Sadly, not a real wand-carrying wizard…
“A computer nerd….is somebody who uses a computer in order to use a computer.”
–Douglas Adams

3. 3
You can virtualize network
functions with it.
You can orchestrate bringing up
and maintaining vast distributed
systems with it.
Or you can just run a few VM’s for
your own use on it.
It scales big, it scales small.
It’s used by huge companies and
one-person cloud admin teams.
OpenStack is incredibly
powerful, flexible, feature-rich
software that’s evolved to
meet the needs of hundreds
of use cases.
You can build public offerings
with it.
You can hook it up to a CI/CD
platform.
You can run e-commerce
apps on it.

4. 4
Likewise.

5. 5
Actually…
doesn’t this
describe an
awful lot of
open source
infrastructure
projects
nowadays?
And a lot of
these are
actually used
together,
right?

6. But this is an OpenStack
talk…right?
Sorta.
(OpenStack is pretty magical…)

7. Turns out, OpenStack is
often used in
conjunction with a lot of
other great software…I
maintain that:
OpenStack is most powerful with it’s friends.
(so we’re going to talk about them too!)

8. Let’s start with a
premise:
Times.
Have.
Changed.
In 2010 we’d have
been having a very
different
conversation.

9. Back in the day, infrastructure was more static. Vendor A and B had totally different offerings.
Choices and alternatives had high barriers to entry, lock in was severe, and changing your
infrastructure often meant choosing between very different ways of doing things.

10. 10
One great thing about the DevOps movement :
It helped us discover the magic of abstraction.
Infrastructure…as code!
Common API’s for multiple underpinnings.

11. 11
We learned to move fast.
We got there by finding the
Interfaces that worked for
us.
(there’s more than one
right answer!)

12. 12
So, let’s say you decide on OpenStack. Great!
How many ways can you get OpenStack?
Pattern? Well…how many ways can you get Kubernetes? Linux?
Storage with an S3 API?
35 distros &
appliances
26 public clouds
17 managed offerings

13. The number of
choices we now
have when we
choose a
technology is
great!
We get to decide
on what’s best for
us operationally
and they look, act,
and feel the same
to the user!
….right?

14. 14
def list_images():
“”” A function to list images. Because all OpenStack Powered Platforms can do that…somehow.””"
if $cloud == ‘vendorA’:
# TODO: this also works for vendorX
list_images_via_nova_image_api()
elif $cloud == ‘vendorB’:
# TODO: this also worked for vendorY last week but now, um?
list_images_via_glance_v1()
elif $cloud == ‘vendorC’:
list_images_via_glance_v2()
else:
# I dunno what cloud this is, but it’s OpenStack Powered! So something must work.
# Resort to trial and error since we don’t know.
try:
list_images_via_nova_image_api()
except NopeError:
# D’oh, guess that wasn’t it…
try:
list_images_via_glance_v1()
except StillNopeError:
# Aww…well third time’s the charm?
try:
list_images_via_glance_v2()
except NopeNopeNopeError:
rage_quit()
This function could
also be called:
not_winning()

15. 15
Somebody tested these claims of interoperability, right?!?
Across versions? Across vendors? Are they actually using the same code?

16. 16
Yup.
http://openstack.org/marketplace

17. 17
First let’s talk about OpenStack’s Interop Working Group.
• Board of Directors working group tasked with creating interop guidelines vendors who want to call
themselves “OpenStack” (using the trademark and logo) must adhere to.
• Interop Guidelines must be approved by the Board, which owns trademarked assets like the name and logo.

18. 18
So what’s a Guideline?
A list of Capabilities that
products must support.
A list of Tests products must
pass to prove it.
A list of Designated Sections
of OpenStack code they must
use to provide those
Capabilities.
Acceptably recent versions of
the software that are covered.

19. 19
• We bake a new Guideline every six months (same as OpenStack’s release
cadence).
• Each Guideline covers the most recent 3 (well…and a half) releases.
• Only the newest two Guidelines can be used to obtain a logo/trademark
agreement with the Foundation.

20. 20
Some things you won’t find in
Interop Guidelines:
• Stuff that end users don’t see or can’t use:
• Admin-only API’s
• RPC API’s
• DB Schema
• HA Requirements
• Stuff that’s intentionally pluggable:
• Virt/net/storage drivers
• Middlewares
• Specific databases
• Stuff that doesn’t have tests
• Stuff that’s being deprecated (usually…more on that in
a minute)

21. 21
How do we decide what gets in? Core Criteria.

22. 22
What if we get something wrong?
Tests can be “flagged” (not required
for the duration of the Guideline) in
some cases:
• Capability fails to meet Criteria
(e.g. was scored incorrectly)
• Test fails/is skipped due to an
accepted bug in the project
• Test fails/is skipped due to an
accepted bug in the test
• Test fails because it requires non-
required Capabilities
• Test reflects an implementation
choice that isn’t widely deployed
even though the Capability itself
is.

23. 23
These programs
offer a degree of
interoperability:
using a core
capability? If you
see the logo, it’ll
work.
But how do I
know what’s
“core” and if I’m
using something
besides that
stuff?

24. 24
We really don’t want to end up back here again.
Locked in.
Hard to move to
something else.
Project might die
because of it.
Can’t use the
tools I want.

25. 25
Start by asking
yourself a
question:
What’s your
interface?

26. 26
If you said “the API”…are you sure?
Are you actually using an abstraction SDK (like jClouds or libcloud)?
Are you actually using a multi-cloud orchestrator (like Terraform or Ansible)?
Are you deploying workloads to containers on top of the IaaS (e.g. Kubernetes clusters)?
If you said “yes” to any of those…you’re probably using a subset of the API under the hood.

27. 27
How will you
use this
cloud?
API?
Terraform
configuration?
Ansible
playbook?
Putting K8s on
top?
Do those work on your
choice of cloud?

28. 28
Trailing indicators of
adoption are often the
easiest way to determine
what capabilities we should
be worried about.
Is this capability abstracted
in libcloud?
Is this capability used by
the Kubernetes provider for
OpenStack?
Is this API used by
CloudFoundry OpenStack
CPI?
Is this capability supported
by Terraform or Ansible?
If so, chances are good it
meets the other Criteria
too.

29. 29
And let’s not forget that multi-cloud is a thing now too.
Different apps. Different needs. Different models. Desire to split availability. Costs.

30. 30
It’s always going to be
a balancing act:
features, abstraction
overhead, freedom
from lock-in vs
simplicity.
But you’ll get there
faster if you start with
a known-safe starting
point.

31. 31
So what about special
use cases with unique
demands? Are they
bad?
No, but you need to
see them for what they
are: special.
“Given time, every sufficiently good and flexible
platform trends toward specialization.”
(Consider Linux…in submarines, seatback entertainment units,
phones, servers, realtime applications.)

32. 32
These clouds may be ”special cases”…
But what matters is still how you choose to interact with them.
If you need to throw out your tools to work with a cloud…that’s not interoperable.

33. 33
OpenStack is working toward
vertical programs already!

34. 34
Clouds are more fun with
friends!
Two fastest-growing
consumption models I see
in the field today:
OpenStack + Kubernetes
OpenStack for NFV

35. 35
Ready to learn more?
• 2017.09 Guideline
• 2017.01 Guideline
• Next Guideline draft
• Public RefStack Server
• OpenStack Interop
Homepage
• Core Criteria
• Interop WG procedural
overview
• Lexicon of Interop WG
terms
• Interop WG wiki &
meeting Info
• How to submit patches

36. 36
Look for interoperable infrastructure. Friends have more fun together.
Your users will thank you.
Any questions?

37. 37
Thank you. Let’s go
make some magic.
@marktvoelker
markvoelker@gmail.com