We should block users from adding to project when we know it will fail.

[ncameronbritt]

We should check for duplicate names BEFORE trying to add to a project to prevent errors, and to avoid a situation where the user has to clean up from a partial success, which can be very difficult in some cases.

[spadgett]

I'm not sure we can since we don't know what objects will be created. The broker handles that.

The template broker could check, but by that point, you already have the service instance object. So you're in the same spot with a failed instance.

In this case, cleanup should be deleting the instance and everything else is garbage collected.

cc @bparees @jwforres

[bparees]

+1 @spadgett

[jwforres]

Agreed we can't check this ahead of time. But I'm wondering if we should be doing something in the creation dialog to let them go ahead and delete the instance when we see provisioning failed, instead of them finding it later on in their project. Unlike the old template processing, there is nothing obvious in this dialog that tells me that there were still objects created.

[spadgett]

Yeah I agree with letting users delete the instance directly from the results step. We have an open issue to add better failure actions (#2217). This might be something easy we can do to make it a little better.

[ncameronbritt]

This situation isn't limited to creating things through the catalog. And (I think) everyone agrees that the experience around this is not good. With the old template processing you see what's created, true, but you still have to go back and delete everything that was created successfully, and we don't make it explicit that that's what you should do (either that or delete your project and start over).

I knew Robb had adding the ability to delete from the results page on his list of to-dos, and adding that delete action is part of the design. But I think it could be argued that preventing what seems like it ought to be a preventable error is preferable to making a mess and then having the user clean it up, even if we make that clean-up process easier.

[jhadvig]

+1 for having the ability to delete the instance in the failed result step. But shouldn't we also have this option in when creating a app not via the service catalog ?

[jwforres]

In theory we could actually do this now that GC is working. We know exactly what we created so we should be able to delete it, its definitely more work though than just deleting the single service instance object. There is a card for this in trello already https://trello.com/c/sV2UFxmK it says "template" but it really applies to new app as well. We have a separate issue that we need to add the existence checks to the new-app flow in the catalog. The full-page new-app flow already attempts to prevent naming conflicts.

…

On Mon, Oct 23, 2017 at 10:05 AM, Jakub Hadvig ***@***.***> wrote: +1 for having the ability to delete the instance in the failed result step. But shouldn't we also have this option in when creating a app not via the service catalog ? [image: dalete] <https://user-images.githubusercontent.com/1668218/31893477-ea928d70-b80b-11e7-9aa6-9964466b0ead.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2297 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZk7Xv8e6DP210Rw_gStrB3NLVmJoPNks5svJ0YgaJpZM4P9uym> .

[spadgett]

@dtaylor113 Has this since been fixed?

[spadgett]

I've verified this is fixed now.

/close