<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div><div class="">Hey everyone,</div><div class=""><br class=""></div><div class="">Thanks for the idea Philip. I do agree that the problem described is something that the broker team needs to fix for the APB developers and we should fix it sooner rather than later.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Shawn </div><blockquote type="cite" class=""><div class="">On Feb 13, 2018, at 2:51 PM, Ryan Hallisey <<a href="mailto:rhallise@redhat.com" class="">rhallise@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Thanks for starting the thread Philip.<br class=""><br class=""></div><div class="">Shawn and John brought to my attention that there were some issues created in the service-catalog recently around this topic. I posted our idea of using a broker config option for "force_delete" in the issue: <a href="https://github.com/kubernetes-incubator/service-catalog/issues/1723" class="">https://github.com/kubernetes-incubator/service-catalog/issues/1723</a> to gather some feedback. <br class=""><br class=""></div><div class="">-Ryan<br class=""></div><div class=""><br class=""></div><div class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 12, 2018 at 4:30 PM, Philip Gough <span dir="ltr" class=""><<a href="mailto:pgough@redhat.com" target="_blank" class="">pgough@redhat.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><span style="font-size:12.8px" class="">Hi all,</span><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">I have had some over and back discussion with the owners of the service broker over IRC and <a href="https://github.com/openshift/ansible-service-broker/pull/751" target="_blank" class="">on this pull request</a> in relation to <a href="https://github.com/openshift/ansible-service-broker/issues/666" target="_blank" class="">issue #666</a>. Ryan suggested I open up this thread for discussion on how we will handle failed deprovisions, whilst remaining compliant to the spec.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">To summarise the conversation, the spec states that "<span style="color:rgb(36,41,46)" class=""><font face="times new roman, serif" class="">When a Service Broker receives a deprovision request from a Platform, it MUST delete any resources it created during the provision</font></span><span style="color:rgb(36,41,46);font-family:-apple-system,system-ui,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol"" class="">.</span>" , my question to Ryan was what happens in the case of a deprovision when the playbook is broken and it fails early. </div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">This leaves potentially many kubernetes resources orphaned within a namespace. Since we don't track this particular resources, we then have no way to delete them later.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">The linked pr sets a flag to overwrite the current behaviour, which is spec compliant with regards to return codes as is. We are wondering what people think the default behaviour should be and what could be done with these untracked resources when a playbook fails.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Regards</div><div class="m_2464343029754601367gmail-yj6qo m_2464343029754601367gmail-ajU" style="margin:2px 0px 0px;font-size:12.8px"></div></div>
<br class="">______________________________<wbr class="">_________________<br class="">
Ansible-service-broker mailing list<br class="">
<a href="mailto:Ansible-service-broker@redhat.com" class="">Ansible-service-broker@redhat.<wbr class="">com</a><br class="">
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank" class="">https://www.redhat.com/<wbr class="">mailman/listinfo/ansible-<wbr class="">service-broker</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>