summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorZane Bitter <zbitter@redhat.com>2018-06-29 13:00:28 -0400
committerZane Bitter <zbitter@redhat.com>2018-06-29 13:05:38 -0400
commitb589194d5c8695e3251cfc4642b306a3efc27727 (patch)
treee34393d4a026c729ab4e0728820143fe2905ac4d
parent61a844205fb9c67f76cd2075db87e1e89c24e30f (diff)
Update README
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] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131183.html Change-Id: I9e7e59756fc73377abb0a75b9aad15712e7b8a31
Notes
Notes (review): Code-Review+2: Artem Goncharov <artem.goncharov@gmail.com> Workflow+1: Artem Goncharov <artem.goncharov@gmail.com> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Fri, 29 Jun 2018 18:10:48 +0000 Reviewed-on: https://review.openstack.org/579230 Project: openstack/openstack-service-broker Branch: refs/heads/master
-rw-r--r--README.rst215
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 http://automationbroker.io/ 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: https://docs.openstack.org/openstack-service-broker/latest
14* Source: https://git.openstack.org/cgit/openstack/openstack-service-broker 15* Source: https://git.openstack.org/cgit/openstack/openstack-service-broker
15* Bugs: https://storyboard.openstack.org/#!/project/1038 16* Bugs: https://storyboard.openstack.org/#!/project/1038
16 17
17-------- 18--------
18 19
19* TODO 20Join Us
21=======
22
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`_.
27
28.. _openstack-dev: http://lists.openstack.org/pipermail/openstack-dev/
29.. _FreeNode: https://freenode.net/
30.. _prototype worklist: https://storyboard.openstack.org/#!/worklist/391
31
32FAQ
33===
34
35What is the Open Service Broker API?
36------------------------------------
37
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.
44
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
49lifecycle.
50
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.)
55
56What sorts of services would OpenStack expose?
57----------------------------------------------
58
59Some example use cases might be:
60
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.)
78
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.
83
84How is this different from cloud-provider-openstack?
85----------------------------------------------------
86
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).
94
95In contrast, the Service Catalog interface allows the *application* running on
96Kubernetes to access features of the cloud.
97
98What does a service broker look like?
99-------------------------------------
100
101A service broker provides an HTTP API with 5 actions:
102
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
108
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.
113
114Is there an easier way?
115-----------------------
116
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`_.
123
124(Aside: Heat uses a comparable method to allow users to manage an external
125resource using Mistral workflows: the OS::Mistral::ExternalResource resource
126type.)
127
128Support for accessing `AWS`_ resources through a service broker is also
129implemented using these Ansible Playbook Bundles.
130
131Does this mean maintaining another client interface?
132----------------------------------------------------
133
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.
139
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
148clouds.
149
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.
160
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.
166
167How would authentication work?
168------------------------------
169
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.
174
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.)
181
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.
186
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.
195
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.
199
200In all cases we'll want to encourage users to authenticate using Keystone
201`Application Credentials`_.
202
203How would network integration work?
204-----------------------------------
205
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
210network.
211
212
213.. _Open Service Broker API: https://www.openservicebrokerapi.org/
214.. _Service Catalog extension: https://kubernetes.io/docs/concepts/service-catalog/
215.. _AWS: https://github.com/awslabs/aws-servicebroker#aws-service-broker
216.. _Azure: https://github.com/Azure/open-service-broker-azure#open-service-broker-for-azure
217.. _GCP: https://github.com/GoogleCloudPlatform/gcp-service-broker#cloud-foundry-service-broker-for-google-cloud-platform
218.. _Cloud Controller: https://github.com/kubernetes/community/blob/master/keps/0002-controller-manager.md#remove-cloud-provider-code-from-kubernetes-core
219.. _cloud-provider-openstack: https://github.com/kubernetes/cloud-provider-openstack#openstack-cloud-controller-manager
220.. _Automation Broker: http://automationbroker.io/
221.. _write Ansible playbooks instead: https://docs.openshift.org/latest/apb_devel/index.html
222.. _clouds.yaml/secure.yaml format: https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#config-files
223.. _Application Credentials: https://docs.openstack.org/keystone/latest/user/application_credentials.html
224.. _Kuryr: https://docs.openstack.org/kuryr/latest/devref/goals_and_use_cases.html