Could you share more on the service you have developed that will not work
if bound to from another org/space?

What extra information would it need to function correctly?

Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some cases
wouldn't be pretty. For example, I have a broker that today on provision
grants an ASG to the space the service is provisioned and removes the ASG
on deprovision. If this service were to be shared I would need to instead
listen on bind get the application the service is being bound to and add an
ASG to that space. Then on unbind I'd need to see if all the applications
in the space with the binding are unbound from the service and remove the
ASG or to cleanup I'd need to continually scan the CC to see if there are
any spaces with this ASG without an instance of the service and clean it
up. Not impossible but a pain for a service that I might not be worth the
effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has had
in the past. We've considered using unbindable services as a way to add
meta data like billing or CI information to a space. This might not be a
service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC. These
brokers might utilize the space guid in some way such as ensuring the space
is authorized to create instances of this service in some billing system,
for example, because this service hasn't been trusted with admin access to
the CC it would have no way to know that another space is also using the
service. This information might be significant to the billing model of the
service.

Adding service broker lifecycle events to notify a broker of sharing and
unsharing might help these types of use cases to be handled by a broker.
But, I think that would not be something prudent to attempt to tackled for
this initial release.

Since the service broker api is one of the few open/stable extension points
on the cloud controller you might be surprised at some of the the odd
things customers have done with custom service brokers. It seems to me that
instead of requiring all services to support sharing it would be prudent to
allow services to opt out (or in) to this new feature.

Thanks,
Mike

On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks for the feedback Mike, and great questions! We're currently
working off slightly different assumptions, but are working through these
to validate that they are the expected behaviour for the majority of users:

* Space developers in the 'owning' space (this is the way we've thought
about this too!) *would *be able to delete or unshare a shared service
instance with bindings, but they would get a warning in the CLI warning
them that this will automatically delete bindings in other spaces.

Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* Space developers can only bind and unbind to service instances that

have been shared into their space. In this first version they wouldn't be
able to remove the service instance from appearing in their space without
asking the sharer to unshare it.

If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?

* We've investigated a number of sharing permission models, including how

both CF admins and service broker authors want to control this. Initial
feedback has suggested that for most use cases, service brokers shouldn't
care where the binding is coming from (it looks the same to them). There
are edge cases here with things like ASGs though which we will need to
consider.

IMO as a broker developer of services that will not function if shared, I
would really like a permission for the broker to opt in/out of services of
it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/
v2.12/spec.md#catalog-management) is too much to ask. Unless there is
some complexity I'm not seeing?


Thanks,
Mike