<div dir="ltr"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">If an async unbind fails, it creates a similar situation to a failed deprovision.</span> This bug for example is a result of the broker deleting its own records of a binding before the cluster-based resources have been deleted:<div><br></div><div><a href="https://github.com/openshift/ansible-service-broker/issues/709">https://github.com/openshift/ansible-service-broker/issues/709</a><br></div><div><br></div><div>I suspect whatever approach we take to deal with this dilemma will work for both cases, but it's worth keeping them both in mind.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 11:29 AM, Ryan Hallisey <span dir="ltr"><<a href="mailto:rhallise@redhat.com" target="_blank">rhallise@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class=""><div><span class="m_917053253369043447gmail-im">>> I don’t know if I feel comfortable with adding this logic to the primary<br>
>> code path for deprovision. This is mostly me being conservative with adding<br>
>> configuration values that can allow things to get deleted from our storage.<br>
>><br>
</span>> The developer experience is not acceptable right now, but I have to<br>
> agree with Shawn.<br>><br></div></span>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:<br><br></div>```go<br><div><span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-pl-k">if</span> a.<span class="m_917053253369043447gmail-pl-smi">brokerConfig</span>.<span class="m_917053253369043447gmail-pl-smi">ForceDelete</span> {<br>  </span><span class="m_917053253369043447gmail-blob-code-inner">log.<span class="m_917053253369043447gmail-pl-c1">Infof</span>(<span class="m_917053253369043447gmail-pl-s"><span class="m_917053253369043447gmail-pl-pds">"</span>Deprovision failed. Attempting to clean up related resources. User should ensure clean up is successful<span class="m_917053253369043447gmail-pl-pds">"</span></span>)</span><br><span class="m_917053253369043447gmail-blob-code-inner"></span><div>  <span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-pl-c1">cleanupDeprovision</span>(&instance, a.<span class="m_917053253369043447gmail-pl-smi">dao</span>) // Return a 200 to the service-catlog</span><br><span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-blob-code-inner">}<br>```<br></span></span></div><span class=""><div><span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-blob-code-inner"><br></span></span>> <span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-blob-code-inner">Unless I missed it, let's backup and describe the high-level problem<br>
> in a proposal and<br>
> submit solutions there. That's been our approach thus far and I think<br>
> it applies here well.<br></span></span></div></span><div><span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-blob-code-inner">To make this the default behaviour, I agree needs a proposal.<span class="HOEnZb"><font color="#888888"><br><br></font></span></span></span></div><span class="HOEnZb"><font color="#888888"><div><span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-blob-code-inner">-Ryan<br></span></span></div><div><span class="m_917053253369043447gmail-blob-code-inner"><span class="m_917053253369043447gmail-blob-code-inner"><br></span></span></div></font></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 10:32 AM, Erik Nelson <span dir="ltr"><<a href="mailto:ernelson@redhat.com" target="_blank">ernelson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I don’t know if I feel comfortable with adding this logic to the primary<br>
> code path for deprovision. This is mostly me being conservative with adding<br>
> configuration values that can allow things to get deleted from our storage.<br>
<br>
</span>The developer experience is not acceptable right now, but I have to<br>
agree with Shawn.<br>
<span><br>
> With that said, I don’t have a well thought out alternative. Off the cuff I<br>
> would suggest that we add an API surface to delete this instance, that would<br>
> only be available if you have a configuration value set something similar to<br>
> dev_broker config.<br>
<br>
</span>Unless I missed it, let's backup and describe the high-level problem<br>
in a proposal and<br>
submit solutions there. That's been our approach thus far and I think<br>
it applies here well.<br>
<span><br>
> I would also like to mention that with the CRD changes that are on the<br>
> roadmap, this is doable just by granting the correct permissions and knowing<br>
> the correct resource to delete with the oc command. This is something that<br>
> we may also want to keep in mind.<br>
<br>
</span>This should be called on on the proposal.<br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Ansible-service-broker mailing list<br>
<a href="mailto:Ansible-service-broker@redhat.com">Ansible-service-broker@redhat.<wbr>com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/ansible-<wbr>service-broker</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>