Re: Proposal: Reducing State in Service Brokers - Service Broker API Enhancement
Dr Nic Williams <drnicwilliams@...>
I think it's a great idea to help make SBs stateless if possible. I've even toyed with modifying service instance tags as the only place in CF API where arbitrary data can be stored (base64 encode the data and append to list of tags) - nasty but was only option. Didn't end up using that as it was just too nasty. Plus the service object didn't actually exist yet during service provisioning:/toggle quoted messageShow quoted text
I like the idea of returning an arbitrary (to CF) last_op_id
But I can imagine that SBs might want to return arbitrary blob of data rather than simple ID, and have CF return with that data.
If you only gave me the ability to return a simple ID string then I would repeat the trick above - I'd construct a JSON object, convert with base64, and return that string as my "ID".
So my ask is to allow the ID value to be an artbitrarily long string pleaze?
On Tue, May 17, 2016 at 9:02 AM -0700, "Alex Ley" <aley(a)pivotal.io> wrote:
I work on a team at Pivotal that builds lots of service brokers. We are currently working on broker that backs onto BOSH and want to move towards making it stateless. We have written a proposal to enhance the CF Service Broker API to allow us to achieve this. We believe this will help other service broker authors as the principal transfers to most asynchronous backing systems.
You can read the full proposal here:
Open to comments on the document and on this thread.