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?

I think the logic of auto-unbinding the service makes sense as long as the
user doing the delete has a way to know that other applications
(potentially in other spaces) are bound to the service and acknowledge that
they wanted to unbind and delete anyway. However, to help even out the
workflow for both shared and unshared services I would recommend having the
CLI team look into changing the current behavior for local service
bindings to match that of shared service binding. That change would be, if
I attempt to delete a service that has local and/or shared service bindings
then the user should be notified of those bindings and confirm the desire
to unbind and delete the service instance anyway.

All that above assumes all unbind requests succeed. Today if an unbind
fails for a local service bound to a local application then the user is
unable to delete that service until the unbind can succeed or they ask an
administrator to "purge" the service instance. I think the behavior should
be the same for a shared service instance binding. If a shared unbind
fails then the service should not be allowed to be deleted until that
unbind succeeds. Unless an administrator purges the service instance.

Thoughts?

Mike