<div dir="ltr"><div><div>>> I don’t know if I feel comfortable with adding this logic to the primary >> code path for deprovision. This is mostly me being conservative with adding >> configuration values that can allow things to get deleted from our storage. >> > The developer experience is not acceptable right now, but I have to > agree with Shawn. > </div>Agreed, the dev experience is really rough with deprovision. For instance, if you are testing your provision playbook with the broker and your deprovision playbook fails, then you can't test provision again without some manually steps. But, I think Phillip's patch is a good way to provide significant improvement to the dev experience with minimal code changes. The meat of his code is 4 lines: </div>```go <div>if a.brokerConfig.ForceDelete { log.Infof("Deprovision failed. Attempting to clean up related resources. User should ensure clean up is successful") <div> cleanupDeprovision(&instance, a.dao) // Return a 200 to the service-catlog } ``` </div><div> > Unless I missed it, let's backup and describe the high-level problem > in a proposal and > submit solutions there. That's been our approach thus far and I think > it applies here well. </div><div>To make this the default behaviour, I agree needs a proposal. </div><div>-Ryan </div><div> </div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Feb 14, 2018 at 10:32 AM, Erik Nelson <<a href="mailto:ernelson@redhat.com" target="_blank">ernelson@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I don’t know if I feel comfortable with adding this logic to the primary > code path for deprovision. This is mostly me being conservative with adding > configuration values that can allow things to get deleted from our storage. The developer experience is not acceptable right now, but I have to agree with Shawn. > With that said, I don’t have a well thought out alternative. Off the cuff I > would suggest that we add an API surface to delete this instance, that would > only be available if you have a configuration value set something similar to > dev_broker config. Unless I missed it, let's backup and describe the high-level problem in a proposal and submit solutions there. That's been our approach thus far and I think it applies here well. > I would also like to mention that with the CRD changes that are on the > roadmap, this is doable just by granting the correct permissions and knowing > the correct resource to delete with the oc command. This is something that > we may also want to keep in mind. This should be called on on the proposal. </blockquote></div> </div>