toggle quoted messageShow quoted text
I agree with both of those thoughts. I'll speak to the CLI time as
consistency across the commands is important, and will ensure that we treat
failed unbinds the same as we do with normal service instances, and that
this prevents the developer from deleting it (and means the admin has to
On Tue, Aug 29, 2017 at 5:00 PM Mike Youngstrom <youngm(a)gmail.com> wrote:
Regarding the unsharing workflow, the app developers we've spoken to
suggested that they would be frustrated if they were not able to unshare orI think the logic of auto-unbinding the service makes sense as long as the
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?
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.