Re: [Proposal] Sharing service instances across orgs and spaces

Matt McNeeney

Hey Mike,

Regarding the unsharing workflow, the app developers we've spoken to
suggested that they would be frustrated if they were not able to unshare or
delete a service instance that they had created. When deleting a service
instance that has bindings in the same space, the *delete-service *command
fails and shows an error stating the service instance has bindings. A
developer can then, if they want to, unbind any applications and then retry
the delete i.e. they are enabled to delete the service instance at any
time; they may just have to run some other commands first. When the service
instance has bindings from another space, that they may or may not have
access to, we'd like to still fully empower developers in the 'owning'
space, and ensure they are never blocked by having to run a command in a
space that they cannot access. (This same logic would apply for deleting a
service instance that has bindings in a shared space).

Does that logic make sense? What are your thoughts on this?

Regarding the org manager deleting a space, I agree that this will remove
any shared services that have been shared *into *that space. I'll
investigate what this workflow could look like for a developer who wants to
remove a service instance that has been shared with them, as I agree this
sounds like a sensible workflow.

Hope this helps. Keep the feedback coming!

On Mon, Aug 28, 2017 at 4:57 PM Mike Youngstrom <youngm(a)> wrote:

Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!
Thanks Matt. It also helps to know that bind will include space and org
guid. Any thoughts on my other comments? For your convenience I've pasted
them below.


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?

Join { to automatically receive all group messages.