diff options
authorZane Bitter <>2018-06-29 13:00:28 -0400
committerZane Bitter <>2018-06-29 13:05:38 -0400
commitb589194d5c8695e3251cfc4642b306a3efc27727 (patch)
parent61a844205fb9c67f76cd2075db87e1e89c24e30f (diff)
Put a fuller description of the state of the project in the README, and copy in the FAQ from the initial project kickoff email[1]. [1] Change-Id: I9e7e59756fc73377abb0a75b9aad15712e7b8a31
Notes (review): Code-Review+2: Artem Goncharov <> Workflow+1: Artem Goncharov <> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Fri, 29 Jun 2018 18:10:48 +0000 Reviewed-on: Project: openstack/openstack-service-broker Branch: refs/heads/master
1 files changed, 210 insertions, 5 deletions
diff --git a/README.rst b/README.rst
index 8ea38ff..41a353b 100644
--- a/README.rst
+++ b/README.rst
@@ -5,15 +5,220 @@ openstack-service-broker
5Builds Ansible Playbook Bundles for use in Automation Broker to expose 5Builds Ansible Playbook Bundles for use in Automation Broker to expose
6OpenStack resources in the Kubernetes Service Catalog. 6OpenStack resources in the Kubernetes Service Catalog.
7 7
8Please fill here a long description which must be at least 3 lines wrapped on 8The project is in the very early stages of development. We will first build a
980 cols, so that distribution package maintainers can use it in their packages. 9prototype that demonstrates the concept of managing OpenStack resources through
10Note that this is a hard requirement. 10the Kubernetes Service Catalog, using the project
11to implement the Open Service Broker API, which in turn uses Ansible playbooks
12to drive the underlying services.
11 13
12* Free software: Apache license 14* Free software: Apache license
13* Documentation:
14* Source: 15* Source:
15* Bugs:!/project/1038 16* Bugs:!/project/1038
16 17
17-------- 18--------
18 19
19* TODO 20Join Us
23* On the `openstack-dev`_ mailing list (use ``[service-broker]`` in the subject
24 line)
25* In ``#openstack-service-broker`` on `FreeNode`_.
26* Working on the `prototype worklist`_.
28.. _openstack-dev:
29.. _FreeNode:
30.. _prototype worklist:!/worklist/391
35What is the Open Service Broker API?
38The `Open Service Broker API`_ is a standard way to expose external resources
39to applications running in a PaaS. It was originally developed in the context
40of CloudFoundry, but the same standard was adopted by Kubernetes (and hence
41OpenShift) in the form of the `Service Catalog extension`_. (The Service
42Catalog in Kubernetes is the component that calls out to a service broker.) So
43a single implementation can cover the most popular open-source PaaS offerings.
45In many cases, the services take the form of simply a pre-packaged application
46that also runs inside the PaaS. But they don't have to be - services can be
47anything. Provisioning via the service broker ensures that the services
48requested are tied in to the PaaS's orchestration of the application's
51(This is certainly not the be-all and end-all of integration between OpenStack
52and containers - we also need ways to tie PaaS-based applications into the
53OpenStack's orchestration of a larger group of resources. Some applications may
54even use both. But it's an important part of the story.)
56What sorts of services would OpenStack expose?
59Some example use cases might be:
61* The application needs a reliable message queue. Rather than spinning up
62 multiple storage-backed containers with anti-affinity policies and dealing
63 with the overhead of managing e.g. RabbitMQ, the application requests a Zaqar
64 queue from an OpenStack cloud. The overhead of running the queueing service
65 is amortised across all of the applications in the cloud. The queue gets
66 cleaned up correctly when the application is removed, since it is tied into
67 the application definition.
68* The application needs a database. Rather than spinning one up in a
69 storage-backed container and dealing with the overhead of managing it, the
70 application requests a Trove DB from an OpenStack cloud.
71* The application includes a service that needs to run on bare metal for
72 performance reasons (e.g. could also be a database). The application requests
73 a bare-metal server from Nova w/ Ironic for the purpose. (The same applies to
74 requesting a VM, but there are alternatives like KubeVirt - which also
75 operates through the Service Catalog - available for getting a VM in
76 Kubernetes. There are no non-proprietary alternatives for getting a
77 bare-metal server.)
79`AWS`_, `Azure`_, and `GCP`_ all have service brokers available that support
80these and many more services that they provide. I don't know of any reason in
81principle not to expose every type of resource that OpenStack provides via a
82service broker.
84How is this different from cloud-provider-openstack?
87The `Cloud Controller`_ interface in Kubernetes allows Kubernetes itself to
88access features of the cloud to provide its service. For example, if k8s needs
89persistent storage for a container then it can request that from Cinder through
90`cloud-provider-openstack`_. It can also request a load balancer from Octavia
91instead of having to start a container running HAProxy to load balance between
92multiple instances of an application container (thus enabling use of hardware
93load balancers via the cloud's abstraction for them).
95In contrast, the Service Catalog interface allows the *application* running on
96Kubernetes to access features of the cloud.
98What does a service broker look like?
101A service broker provides an HTTP API with 5 actions:
103* List the services provided by the broker
104* Create an instance of a resource
105* Bind the resource into an instance of the application
106* Unbind the resource from an instance of the application
107* Delete the resource
109The binding step is used for things like providing a set of DB credentials to a
110container. You can rotate credentials when replacing a container by revoking
111the existing credentials on unbind and creating a new set on bind, without
112replacing the entire resource.
114Is there an easier way?
117Yes! Folks from OpenShift came up with a project called the `Automation
118Broker`_. To add support for a service to Automation Broker you just create a
119container with an Ansible playbook to handle each of the actions
120(create/bind/unbind/delete). This eliminates the need to write another
121implementation of the service broker API, and allows us to simply `write
122Ansible playbooks instead`_.
124(Aside: Heat uses a comparable method to allow users to manage an external
125resource using Mistral workflows: the OS::Mistral::ExternalResource resource
128Support for accessing `AWS`_ resources through a service broker is also
129implemented using these Ansible Playbook Bundles.
131Does this mean maintaining another client interface?
134Maybe not. We already have per-project Python libraries, (deprecated)
135per-project CLIs, openstackclient CLIs, openstack-sdk, shade, Heat resource
136plugins, and Horizon dashboards. (Mistral actions are generated automatically
137from the clients.) Some consolidation is already planned, but it would be great
138not to require projects to maintain yet another interface.
140One option is to implement a tool that generates a set of playbooks for each of
141the resources already exposed (via shade) in the OpenStack Ansible modules.
142Then in theory we'd only need to implement the common parts once, and then
143every service with support in shade would get this for free. Ideally the same
144broker could be used against any OpenStack cloud (so e.g. k8s might be running
145in your private cloud, but you may want its service catalog to allow you to
146connect to resources in one or more public clouds) - using shade is an
147advantage there because it is designed to abstract the differences between
150Another option might be to write or generate Heat templates for each resource
151type we want to expose. Then we'd only need to implement a common way of
152creating a Heat stack, and just have a different template for each resource
153type. This is the approach taken by the AWS playbook bundles (except with
154CloudFormation, obviously). An advantage is that this allows Heat to do any
155checking and type conversion required on the input parameters. Heat templates
156can also be made to be fairly cloud-independent, mainly because they make it
157easier to be explicit about things like ports and subnets than on the command
158line, where it's more tempting to allow things to happen in a magical but
159cloud-specific way.
161I'd prefer to go with the pure-Ansible autogenerated way so we can have support
162for everything, but looking at the `GCP`_/`Azure`_/`AWS`_ brokers they have 10,
16311 and 17 services respectively, so arguably we could get a comparable number
164of features exposed without investing crazy amounts of time if we had to write
165templates explicitly.
167How would authentication work?
170There are two main deployment topologies we need to consider: Kubernetes
171deployed by an OpenStack tenant (Magnum-style, though not necessarily using
172Magnum) and accessing resources in that tenant's project in the local cloud, or
173accessing resources in some remote OpenStack cloud.
175We also need to take into account that in the second case, the Kubernetes
176cluster may 'belong' to a single cloud tenant (as in the first case) or may be
177shared by applications that each need to authenticate to different OpenStack
178tenants. (Kubernetes has traditionally assumed the former, but I expect it to
179move in the direction of allowing the latter, and it's already fairly common
180for OpenShift deployments.)
182The way e.g. the `AWS`_ broker works is that you can either use the credentials
183provisioned to the VM that k8s is installed on (a 'Role' in AWS parlance - note
184that this is completely different to a Keystone Role), or supply credentials to
185authenticate to AWS remotely.
187OpenStack doesn't yet support per-instance credentials, although we're working
188on it. (One thing to keep in mind is that ideally we'll want a way to provide
189different permissions to the service broker and cloud-provider-openstack.) An
190option in the meantime might be to provide a way to set up credentials as part
191of the k8s installation. We'd also need to have a way to specify credentials
192manually. Unlike for proprietary clouds, the credentials also need to include
193the Keystone auth_url. We should try to reuse openstacksdk's
194`clouds.yaml/secure.yaml format`_ if possible.
196The OpenShift Ansible Broker works by starting up an Ansible container on k8s
197to run a playbook from the bundle, so presumably credentials can be passed as
198regular k8s secrets.
200In all cases we'll want to encourage users to authenticate using Keystone
201`Application Credentials`_.
203How would network integration work?
206`Kuryr`_ allows us to connect application containers in Kubernetes to Neutron
207networks in OpenStack. It would be desirable if, when the user requests a VM or
208bare-metal server through the service broker, it were possible to choose
209between attaching to the same network as Kubernetes pods, or to a different
213.. _Open Service Broker API:
214.. _Service Catalog extension:
215.. _AWS:
216.. _Azure:
217.. _GCP:
218.. _Cloud Controller:
219.. _cloud-provider-openstack:
220.. _Automation Broker:
221.. _write Ansible playbooks instead:
222.. _clouds.yaml/secure.yaml format:
223.. _Application Credentials:
224.. _Kuryr: