Thanks for the feedback all. It sounds like there are a mix of brokers out
- some are totally stateless
- some manage their own state
- some can rely on other components (like BOSH) or things like names and
tags to hold state
Knowing this, I will try to ensure to ensure than the Open Service Broker
API specification continues to support all of these setups and that any new
features that require state will be optional for brokers to support.
On Fri, 20 Oct 2017 at 11:22, Sascha Matzke <sascha.matzke(a)didolo.org>
we have several internally used brokers.
While we try to avoid keeping state in the broker (by encoding the state
in backend instances names, tags or everything else that can hold
information and allows to query it), we couldn't avoid in all cases.
So yes, our brokers partially keep state and most of them also support
async operations (but that's not directly coupled to whether or not they
On Thu, Oct 19, 2017 at 2:58 PM, Matt McNeeney <mmcneeney(a)pivotal.io>
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 (
provisioning) and features that we want to get into the spec (allowing
platforms to GET
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
*CF Services API PM*
Through the darkness of future past
the magician longs to see
One chants out between two worlds
*Fire walk with me*.