A few weeks ago I asked for feedback on this document, and we've had
several useful conversations as a result of your feedback. Thank you to
the people who have been participating! We're excited to release this new
API shortly and enable the community to begin to use it.

https://docs.google.com/a/pivotallabs.com/document/d/1qXnEI0pfTs_nUq4w4iMr3RHknLYgFDTYvOe76hugg28/edit#

We've incorporated many of the suggestions you've all provided, and I
wanted to send out an email to discuss why we haven't implemented some
other suggestions.

*CC providing the ID for instances and bindings*
This area has been the subject of many complaints, but we've kept it as
originally designed in an effort to balance 2 concerns: making broker
authors implement as few endpoints as possible, and preventing orphaned
services. Several alternatives were proposed, but all of them involved
adding more endpoints or not preventing orphans. We know that some number
of brokers will not be able to use the IDs we provide to identify a
resource, even though they are just GUIDs, and that we are forcing those
brokers to become stateful so they can map our IDs to theirs. Based on my
own experience developing brokers, I suspect that many of these brokers
will eventually have to maintain state as they develop more advanced
feature sets anyway.

For example, to keep our MySQL service broker stateless, we use the
instance GUID as the database name (after removing the dashes). We
likewise use the binding GUID as the username (after removing dashes).
  These guids will always be composed of 0-9A-Z and dash, so they should be
usable as broker identifiers in most cases. As we continue to add
features, we eventually will have to keep state on our broker, but have
managed to avoid it so far.

*Gateway Data field*
Allowing brokers to store some data in CCDB seems to solve many problems
for the brokers, but that state would have to be immutable and passed on
every request. I believe that brokers will eventually want to break that
immutability and change their GW data over time, which really means that
they should have been stateful to begin with.

*User IDs*
Services should not be aware of individuals, as a space is the owner of a
service instance. If a user is trusted by the space owner to act on a
space, then the service broker should not care who they actually are.
  Providing user information encourages broker authors to pay attention to
concepts that don't have meaning in CF.


We appreciate all the feedback we've received from the community and expect
to have a *finalized API in the next week* as part of the public
documentation.

--
-David Stevenson
Director of Engineering, CF Services

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedOct 25, '13 at 5:54p
activeOct 25, '13 at 5:54p
posts1
users1

1 user in discussion

David Stevenson: 1 post

People

Translate

site design / logo © 2021 Grokbase