Re: How stateless are service brokers?
Dr Nic Williams <drnicwilliams@...>
Two stateless brokers I can think of are:
* cf-containers-broker - all its state is moved into Docker container metadata (broker API guids become Docker container names; parameters become env vars for containers)
* cf-subway - it allocates incoming requests to a random backend; one day it might have an in memory cache of what it remembers about its backend service broker APIs
The former could probably look up its state from Docker API. The latter could delegate its lack of local state to the backend APIs that would have the new stateful APIs (GET).
I would like to see the OSBAPI expanded to add GET commands.
From: Matt McNeeney <mmcneeney(a)pivotal.io>
Sent: Thursday, October 19, 2017 10:58:31 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] How stateless are service brokers?
Members of the Open Service Broker API<https://www.openservicebrokerapi.org/> group are currently asking about how stateless service brokers really are. There are features in the spec (asynchronous<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#asynchronous-operations> instance provisioning) and features that we want to get into the spec (allowing platforms to GET<https://github.com/openservicebrokerapi/servicebroker/pull/333> instances and bindings) that we believe require some degree of statefulness, and so we want to understand this space better before making these changes.
I'm keen to understand from Service Broker authors whether or not the service brokers you have created keep any state (either on their own or by relying on other platform components), and if not, whether or not you currently support or plan to support asynchronous operations (provisioning and binding)?
CF Services API PM