<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">+1 that is also what I was thinking<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2018, at 12:16 PM, David Zager <<a href="mailto:dzager@redhat.com" class="">dzager@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I agree with having bind/unbind playbooks that are called on those actions. However, in this case at least, a bind playbook didn't place the secret in the deployment config, the Openshift ?Console? did. This sounds like a bug against origin. If there is a process for adding the secret to the deployment then there should be a process that removes it.</div><span class="">
</span><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jan 4, 2018, 11:59 AM Dylan Murray <<a href="mailto:dymurray@redhat.com" target="_blank" class="">dymurray@redhat.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I like it. Makes sense and fits the inital approach we wanted to take. It would also be useful for Amazon APBs to remove credentials from RDS for example.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jan 4, 2018 at 11:07 AM, Ryan Hallisey <span dir="ltr" class=""><<a href="mailto:rhallise@redhat.com" target="_blank" class="">rhallise@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">Michael,<br class="">
<br class="">
I agree there is a gap here. In the past with pod presets, the<br class="">
catalog managed the relationship<br class="">
between the app and the bind. Until the catalog has another solution,<br class="">
maybe we can deal with<br class="">
this with an unbind apb playbook. The playbook will get called from<br class="">
the broker unbind action,<br class="">
an apb will run for each app in the bind, and the reference to the<br class="">
secret will be removed by the<br class="">
playbook.<br class="">
<br class="">
What are folks thoughts on that?<br class="">
<br class="">
Thanks,<br class="">
- Ryan<br class="">
<div class=""><div class="m_-2463993673162599319m_-5981628092474769611h5"><br class="">
<br class="">
On Wed, Jan 3, 2018 at 5:10 PM, Michael Hrivnak <<a href="mailto:mhrivnak@redhat.com" target="_blank" class="">mhrivnak@redhat.com</a>> wrote:<br class="">
> Looking at this BZ, and continuing a discussion from IRC:<br class="">
> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1511760" rel="noreferrer" target="_blank" class="">https://bugzilla.redhat.com/show_bug.cgi?id=1511760</a><br class="">
><br class="">
> It seems there is a gap in the lifecycle of the secret that gets created by<br class="">
> a binding. When the ServiceBinding gets deleted (such as via the binding's<br class="">
> "Delete" link in the UI), its secret gets deleted too. But if that secret<br class="">
> had been added to a DeploymentConfig, that DC retains a reference to the<br class="">
> secret. Any re-deployment will fail.<br class="">
><br class="">
> What is the missing step? Something should presumably clean up any<br class="">
> references to the secret, which in this case would mean updating the<br class="">
> DeploymentConfig. What should implement that business logic?<br class="">
><br class="">
> --<br class="">
><br class="">
> Michael Hrivnak<br class="">
><br class="">
> Principal Software Engineer, RHCE<br class="">
><br class="">
> Red Hat<br class="">
><br class="">
><br class="">
</div></div>> _______________________________________________<br class="">
> Ansible-service-broker mailing list<br class="">
> <a href="mailto:Ansible-service-broker@redhat.com" target="_blank" class="">Ansible-service-broker@redhat.com</a><br class="">
> <a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank" class="">https://www.redhat.com/mailman/listinfo/ansible-service-broker</a><br class="">
><br class="">
<br class="">
_______________________________________________<br class="">
Ansible-service-broker mailing list<br class="">
<a href="mailto:Ansible-service-broker@redhat.com" target="_blank" class="">Ansible-service-broker@redhat.com</a><br class="">
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank" class="">https://www.redhat.com/mailman/listinfo/ansible-service-broker</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">
Ansible-service-broker mailing list<br class="">
<a href="mailto:Ansible-service-broker@redhat.com" target="_blank" class="">Ansible-service-broker@redhat.com</a><br class="">
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank" class="">https://www.redhat.com/mailman/listinfo/ansible-service-broker</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Ansible-service-broker mailing list<br class=""><a href="mailto:Ansible-service-broker@redhat.com" class="">Ansible-service-broker@redhat.com</a><br class="">https://www.redhat.com/mailman/listinfo/ansible-service-broker<br class=""></div></blockquote></div><br class=""></body></html>